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

[Dmitry Kurochkin]

On Thu, 15 Dec 2011 20:27:34 +0100, Michael Albinus <address@hidden> wrote:
> Dmitry Kurochkin <address@hidden> writes:
> 
> > 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.
> 
> Maybe. But Tramp checks alao the system via "uname -sr". If the result
> does not match the previous invocation on that system, Tramp flushes all
> cache entries.
> 
> > 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?
> 
> If you set `file-precious-flag' to t, Tramp verifies every write action
> (including a call of "cksum" on both the local and remote side). That
> shall be reasonable.
> 

`file-precious-flag' files edited locally as well.  Also, checksum
calculation may be an overkill, especially on embedded systems.  On the
other hand, checking the file size does not add any overhead, since we
already have it.

Actually, checking file size is good but not enough, because it is done
after the file is written.  IMHO in addition to the uname check, TRAMP
should retest the cached encoder and decoder when it connects and wipe
the cache if it fails.

I understand that my situation is not common.  But we are risking of
silently wiping out files on a remote system, so it does not hurt to
take some extra caution IMO.

Regards,
  Dmitry

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