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

[Dmitry Kurochkin]

Hi Michael.

On Sun, 18 Dec 2011 11:42:51 +0100, Michael Albinus <address@hidden> wrote:
> Dmitry Kurochkin <address@hidden> writes:
> 
> >> 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.
> 
> Yes, I know that disadvantage of using `file-precious-flag' inside
> Tramp. OTOH, I try to avoid introducing Tramp specific variables,
> because we want to customize such checks in general. Tramp shall not
> monopolize remote file access; we have also ange-ftp, and there might be
> other packages in the future.
> 
> > Also, checksum calculation may be an overkill, especially on embedded
> > systems.
> 
> IIRC, the cksum test was introduced when the sending/receiving of file
> chunks lacked an error in `process-send-string'. A simple test of file
> size wasn't sufficient. I don't know wether this specific bug has been
> fixed meanwhile in Emacs.
> 
> The usage of `file-precious-flag' in Tramp is intended for cases we fear
> a bug in Tramp or the underlying libraries. It shall be limited until we
> know what happend and we have found a sufficient solution for this
> specific problem.
> 
> > On the other hand, checking the file size does not add any overhead,
> > since we already have it.
> 
> It's more a problem of the control flow in Tramp. There are several ways
> to cache file data for reuse, which we would break. Therefore, checking
> for file size shouldn't be enabled by default but in special cases only.
> 
> > 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.
> 
> Why that? It is checked when used for the very first time. In your case,
> there was a bug in that check; this is fixed now. I believe we could
> trust this check as long as "uname -sr" does not return a changed
> value. That's the basic idea for all cached connection properties, not
> only for the encoder/decoder. Otherwise, we couldn't use cached
> connection properties anyway, and we should recompute them every time
> they are used.
> 

It is possible that the command TRAMP uses for decoding was just
removed.  What would happen then?  As I understand, TRAMP would print an
error that write failed because the command would fail.  But at the same
time it would wipe out the file because output is done via a
redirection.

Of course, it is still possible that the decoder was removed after TRAMP
did the initial check and before the actual write happens.  But that has
lower chances.

Another (and probably better) option may be to add "which command &&" or
similar to all decoders.

BTW if TRAMP finds that remote encoder/decoder fails, does it start
checking for a working encoder/decoder again?

> > 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.
> 
> I do agree that this is important. But we must find a reasonable balance
> between checking any remote command result, and performance.
> 

Agreed on performance.

Regards,
  Dmitry

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