Re: Corruption bug fixed in 2.1.8?

[Michael Albinus]

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'
...data...
EOF
10:44:07 tramp-wait-for-regexp (6) # 
Warning: base64 decoder saw premature EOF!

///46145ad18f32a442bd218d5cb85cbc3f
---

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

///46145ad18f32a442bd218d5cb85cbc3f
---

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.