@cosb: This topic is about downloads. Your problem seems to be with uploads. So very different. What protocol are you using?
- martin
Post a reply
Before posting, please read how to report bug or request support effectively.
Bug reports without an attached log file are usually useless.
Topic review
- cosb
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.
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.
- Guest
"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.
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.
- martin
@cosb: Unfortunately not.
- cosb
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.
- martin
Re: Receiving 0 byte files
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.
- Berube
More failures
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.
- martin
Re: Zero-length files
Please increase logging level to Debug 2 and post again logs of one successful and one zero transfer.
- Berube
Zero-length files
The files with zero length were:
The original files did have content on the server.
ym_lims_export_20240703000027.txt
ym_lims_export_20240703000029.txt
ym_lims_export_20240703000031.txt
The original files did have content on the server.
- martin
Re: Receiving 0 byte files
@Berube: Please give us a name of a file that has 0 bytes and a file that was transferred correctly (in the log).
- Guest
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.
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
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:
I have noticed something unusual in the logs. When a successful transfer occurs, the log entries contain:
< 2024-07-03 01:20:06.643 150 Opening BINARY mode data connection.
. 2024-07-03 01:20:06.689 Session ID reused
. 2024-07-03 01:20:06.689 Using TLSv1.2, cipher TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
. 2024-07-03 01:20:06.689 TLS connection established
. 2024-07-03 01:20:06.736 Data connection closed
< 2024-07-03 01:20:06.736 226 Transfer complete.
However, when we get a 0 byte file, the "Session ID reused" line is missing:
< 2024-07-03 01:20:06.924 150 Opening BINARY mode data connection.
< 2024-07-03 01:20:07.049 226 Transfer complete.
. 2024-07-03 01:20:07.090 Data connection closed