Re: [BUG] TRAMP 2.1.20: "uudecode -o /dev/stdout" check

[Dmitry Kurochkin]

On Thu, 15 Dec 2011 19:32:59 +0100, Michael Albinus <address@hidden> wrote:
> Dmitry Kurochkin <address@hidden> writes:
> 
> > Hi Michael.
> 
> Hi Dmitry,
> 
> >> Thanks for confirmation, I've committed the patch to the Tramp
> >> repository. Will appear with Tramp 2.2.4.
> >
> > Cool.  So it will be part of Emacs 24, right?
> 
> Nope. Emacs 24.1 is sync'ed with Tramp 2.2.3, due to the pretest of
> Emacs I'll commit only additional fixes for serious bugs. This one
> you've reported does not seem to touch the majority of users.
> 
> >> I beg you pardon, but it does check it. Could you, please, detail what
> >> you are missing?
> >
> > Here is the code that checks if a remote encoder and decoder work:
> >
> >                "Checking remote decoding command `%s' for sanity" rem-dec)
> >               (unless (tramp-send-command-and-check
> >                        vec
> >                        (format "echo %s | %s | %s" magic rem-enc rem-dec)
> >                        t)
> >                 (throw 'wont-work-remote nil))
> >
> > (this is from Emacs trunk, but the code in the patch you sent is
> > essentially the same)
> >
> > It checks that the command exits with zero status code, but does not
> > check that it's output is the same as input, i.e. `magic'.  If it did,
> > then I would not found the original issue, because "uudecode -o
> > /dev/stdout" does not output anything on the affected system and the
> > check would fail (it would still create /dev/stdout file, but I would
> > not notice that).
> 
> And the next lines read
> 
>                 (with-current-buffer (tramp-get-buffer vec)
>                   (goto-char (point-min))
>                   (unless (looking-at (regexp-quote magic))
>                     (throw 'wont-work-remote nil)))
> 
> This code checks the returned string, as contained in the connection
> buffer.
> 

Indeed.

> I don't know, why this check hasn't raised an alarm on your remote system.
> 

I did some more testing and debugging, the above code correctly detects
that the decoder does not work.  My best theory is that the decoder
selection was saved in the cache from a previous system running using
the same IP or the same system running a different image.

It seems that TRAMP tries to verify that the file was successfully
saved.  I see the following in the debug log:

  23:07:30.338776 tramp-send-string (10) # (test -e /home/root/yyy || test -h 
/home/root/yyy) && /bin/ls --color=never -ildn /home/root/yyy
  ...
    14798 -rw-r--r--    1 0        0                0 Dec 15 23:08 
/home/root/yyy

Since TRAMP gets the ls output anyway, perhaps it can verify that the
file size matches the expected one?

Regards,
  Dmitry

> > Regards,
> >   Dmitry
> 
> Best regards, Michael.