On 2017-07-16 12:23, Carl Hartung wrote:
On Sun, 16 Jul 2017 08:45:12 +0100 Richmond Richmond wrote:
Carl Hartung <> writes:
On Sat, 15 Jul 2017 23:27:53 +0100 Richmond Richmond wrote:
Roger Price <roger@rogerprice.org> writes:
On Sat, 15 Jul 2017, Richmond wrote:
I created a 12G tar archive on another computer using nfs. I then brought that archive back again using sftp. Although the size was correct, the archive was corrupted. sha256 values did not match. When I brought it back by nfs again it was fine.
Is this problem reproducible?
It took 5 hours! I am pretty sure I have had this happen to me before. I have lost confidence in it. But for small transfers it is probably OK.
I read somewhere it doesn't do much error checking but I cannot find the page now.
Are all the files regular files, binary or text, or are there more exotic file types present?
There were all sorts of things. It was a backup of /home
The "other computer" was running slackware 14.2.
Have you conflated 'sftp' with 'ftps?' These are two completely different protocols. Your 'p.s.' comment makes me concerned that this is what's happened since ftps is true ftp but over a secure connection, including binary vs text mode operational concerns.
No I have no ftps command on my system. I am using sftp from the package openssh-7.2p2-9.1.x86_64.
I mentioned binary mode only because I had seen it when searching, and remembered it from old ftp days.
Despite the 'ftp' name, you are not using ftp at all, but ssh.
Thanks for the clarification. It rules out a huge swath of possible explanations. An experience like the one you've written about would spoil my day. I'd be compelled to the point of distraction and studying logs at both ends to understand the cause. I've used scp, sftp and rsync for a great many years to transfer an incredibly diverse range of file types and sizes server to server, including gzipped tar archives that were dozens and even hundreds of GBs in size, and I can't recall a single instance where the file size was consistent but the archive failed to decompress and unpack.
It is indeed very worrying. rsync is different from the rest, because it does, or can do, checksums, and download the part that is corrupted again. But this error maybe just one occurrence in may. Files are very big, so the chances increase. None of those protocols, except rsync, does verification. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)