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

[Michael Albinus]

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.

> 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.

> Regards,
>   Dmitry

Best regards, Michael.