Receiving 0 byte files

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:

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.

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

The files with zero length were:
The original files did have content on the server.

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

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.

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

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.

@cosb: Unfortunately not.

"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.

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.

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