On Thu, 15 Dec 2011 20:27:34 +0100, Michael Albinus <[email protected]> wrote: > Dmitry Kurochkin <[email protected]> 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. _______________________________________________ Tramp-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/tramp-devel
