Thanks for the details. What version of OpenSSH? I have 7.7 and I cannot reproduce the problem.

If you start a transfer, interrupt it in a middle, disconnect, reconnect and resume the transfer, do you get the same problem?

Here is the relevant part of the log files.

Hello

The server I had problems with was running the OpenSSH for Windows (the one delivered by Microsoft in Win10).
It seems that when I put the transfer in the background, there is a cut, then a resume, and that's around there I see a difference in the file.

I just had a look at the binary files, and to summarize:
Let's say I have "original.file", which is 1GB. I transfer it on the foreground for 100MB, then decide to put it in the background.
What happens when examining "altered.file", is that the first 100MB are just completely filled with zeros. The rest of the file is matching perfectly the original.
The size is also exactly the same.

Something fishy seems to occur during the resume, for whatever reason. File space is reallocated, and filled with blanks then, before the transfer can continue where it was interrupted.

Can you use some binary file compare tool to check, at what place does the file differ against the original? What SSH/SFTP server is that? Is it possible to get a test account on your server?

The relevant file is named file.mkv.
When checking for file integrity, I've checked the file size, which was correct every time, but the SHA1 checksum was different during 2nd and 3rd transfer (when I put the file in background transfer).
Not sure it's the real reason, but seemed to be a recurrent pattern.

Thanks for your report.
Can you name a specific file that got corrupted, which we should check for in the log file?

Hello

I've been trying to migrate to WinSCP several times until now, but somehow always had to come back to my former client to handle transfers between my NAS and my laptop.
This time I decided to dig into the issue, and may have found a pattern.

Basically, it seems that the files are transferred correctly as long as I don't change the front/backward kind of transfer.
Started backward => OK
Started frontward => OK
Started frontward, then set to backward sometime during the transfer => corruption

On the attached log, the 1st and 4th transfer were fine. The 2nd and 3rd led to erroneous files.