[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Corruption bug fixed in 2.1.8?

From: Michael Albinus
Subject: Re: Corruption bug fixed in 2.1.8?
Date: Wed, 10 Jan 2007 22:35:05 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux)

Kirk Strauser <address@hidden> writes:

> Now, I'm *not* blaming Tramp for this; it's certainly possible that 
> something like mimedecode is broken.  However, the only time I see this 
> data corruption is when using Tramp to save to remote files.  I'm certain 
> that I'd heard this problem mentioned before, but I can't find the thread 
> discussing it.  I'll keep looking.

The traces you've sent me are instructive. Let's follow level 6
messages, these are sent commands and the corresponding answers:

10:44:07 tramp-send-command (6) # mimencode -u -b 
>/usr/local/etc/apache22/httpd.conf <<'EOF'
10:44:07 tramp-wait-for-regexp (6) # 
Warning: base64 decoder saw premature EOF!


mimencode has detected that there is a problem. Either with these
data, either due to a previous quit.

10:44:07 tramp-send-command (6) # echo tramp_exit_status $? 
10:44:08 tramp-wait-for-regexp (6) # 
tramp_exit_status 0


Tramp checks $?, the return code of mimencode. The remote host says
"0", so Tramp believes the transfer is OK. So Tramp has no chance to
be informed about the problem :-(

You are running "FreeBSD 6.2-PRERELEASE" on the remote host. This is
known for problems in receiving larger chunks of data. According to
your traces, Tramp has already set tramp-chunksize to 500 because of
this. Maybe you try even a smaller value.

Another counter measure is to set file-precious-flag to t. Then, Tramp
computes a cksum of every transferred file, and raises an error when it
doesn't match. By this, you are at least warned in case of problems.

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]