Hi,
I have more information about this issue.
Let's say I want to transfer a file between computer 1 and computer 2. For whatever reason, when the file transfer takes place, the size of the destination file created on computer 2 is 0 for a while until the file is transferred completely. I noticed this when I used the File Transfer Resume = on. I copied a big file using a local openssh ssh server for microsoft and I refreshed repeatedly windows explorer and the .filepart file still showed size 0. A quick search shows this might be a windows "issue": https://devblogs.microsoft.com/oldnewthing/20111226-00/?p=8813.

Anyway, I will switch to File Transfer Resume = on and this should address the issue once and for all (on computer 2 .filepart files will be ignored by the application that has to process these files).

@cosb: This topic is about downloads. Your problem seems to be with uploads. So very different. What protocol are you using?

Thank you for your reply.

The files that had this issue were small, under 1,600 bytes. 100% sure they contained at least 1 byte, so their length was not 0. My understanding is that these small files are loaded in the memory and shipped over the fence. The problem is that I don't know what kind of processing they do on the server side - do they start processing a file immediately as soon as the file was created but not populated with data? Is it even possible? I don't even know what software/version they use. We had the system for over 6 years, and after 6 years I started to see this issue twice, approx. 3 months apart.

I ended up changing my app and after the PutFiles and Check calls, I query the remote file information using EnumerateRemoteFiles. I am not crazy about this but what else can I do?

In a way it is interesting, it shows that this protocol is not 100% reliable, like, let's say a database transaction which guarantees all the the data is saved or none. Originally,I thought that if the Check call succeeds, it means with 100% certitude the file made it on the other side and is identical with the source file.

If you have other thoughts or ideas, please let me know.

"very rarely (1 time every roughly 3 months) and I am trying to figure out if it is a problem with the server software."

If there's an issue after server side preps an empty file, and doesn't clean up, it will result in a 0 byte (empty) file. This could be possibly difficult for non-programmers to fully understand. It is something that is possible and it can be rare. Weird things can happen on rare times with this as the result.

I would say it could be the client only if its up to the client to determine such as during WinSCP Synchronize as one example. For that, it can be doing checks (although also not always as such eg HASH for file size check are up to the user to use or not use). If checks are done and the original isn't 0 byte, then 0 bytes should only happen under situations where the client cannot connect and do its thing to correct or fail.

I'm not aware of any other situations that create 0 byte files where the original isn't. However, scripting and user are another direction, as scripts may not be written to do checks and can see various file issues. Maybe in an exceptionally rare situation something else could happen.

@cosb: Unfortunately not.

Hi Martin - do you ever figure out the issue here? I am experiencing the same issue, though very rarely (1 time every roughly 3 months) and I am trying to figure out if it is a problem with the server software.

I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Attached is the log from last night's transfers with logging at debug 2. Four files failed, those with filenames ending in 31, 32, 37, & 38.

Please increase logging level to Debug 2 and post again logs of one successful and one zero transfer.

The files with zero length were:

The original files did have content on the server.

@Berube: Please give us a name of a file that has 0 bytes and a file that was transferred correctly (in the log).

Martin can of course look at the log (I can't as I'm just a guest).

But, if you know that the file on the server is indeed not 0 byte, then it makes sense that WinSCP is creating a file but is unable to get bytes into it. This can be from a connection issue such as with networking equipment. However, if WinSCP creates a file before the server gets into the read file loop, and the server has an issue, WinSCP could in theory leave a 0 byte file around.

I'm not looking at the code or anything.

Session resumption involving session id has nothing to do with this.

We have a recurring problem with a script that runs nightly; it works most of the time, but we occasionally get files with no contents. The log from last night is attached; the problem occurred three times last night.

I have noticed something unusual in the logs. When a successful transfer occurs, the log entries contain:

However, when we get a 0 byte file, the "Session ID reused" line is missing: