"Preserve timestamps of transferred files" option not working correctly

Need help with FileZilla Client? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
limmy
500 Command not understood
Posts: 4
Joined: 2019-08-20 11:27

"Preserve timestamps of transferred files" option not working correctly

#1 Post by limmy » 2019-08-20 12:14

Summary:
"Preserve timestamps of transferred files" option not working correctly when downloading takes a long time.

Detailed description of the symptom:
I am using latest version of FileZilla client on a Windows machine.

The "Preserve timestamps of transferred files Ctrl+U" option works most of the time, but when I download a large file from my server (personal Synology FTP server) the timestamp is NOT preserved and the modified date is set as the downloaded time.

It seems that when it takes long time to download, the client cannot update the timestamp of the downloaded file.

I think it has something to do with connection being closed while files are being downloaded. I tried to solve the issue by disabling connection timeout setting on my client (Settings>Connection>Timeout>Set to 0), but the problem persists. (Although client does not close connection, server can disconnect I think) Examining the log, I see that my FIleZilla client tries to get the directory listing of the server when the file transfer is complete, presumably to get the source file timestamp, but it fails because of the disconnection due to inaction. When I downloaded one large file, I left the client alone and I did not browse the server folders. I guess this broke the connection that enables directory listing.

The following instance backs my conjecture. When I download TWO large files with similar size, only the timestamp of one file (usually larger file) is updated. I think the client attempts to connect when it finishes downloading the smaller file yet fails to update the timestamp, but once the connection is resumed the timestamp gets properly updated by the time the second file download is complete.

I think this problem can be solved by either
1. getting the source file timestamp before downloading
2. ensure to update timestamp of the download file when directory listing is complete after connection is resumed

User avatar
botg
Site Admin
Posts: 32321
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: "Preserve timestamps of transferred files" option not working correctly

#2 Post by botg » 2019-08-20 16:44

Please post a log of such a download.

User avatar
boco
Contributor
Posts: 24644
Joined: 2006-05-01 03:28
Location: Germany

Re: "Preserve timestamps of transferred files" option not working correctly

#3 Post by boco » 2019-08-20 17:42

Unfortunately, timeout on the Synology FTP server can be set to 2 hours tops (7200 secs).

As a workaround, repeat the transfers with "Resume". It will not transfer a single Byte (as the files exist) but set timestamps nonetheless. Note: If support for FTP ASCII transfers is enabled on the Synology device, this method will not work for text files.
### BEGIN SIGNATURE BLOCK ###
No support requests per PM! You will NOT get any reply!!!
FTP connection problems? Do yourself a favor and read Network Configuration.
All FileZilla products fully support IPv6. http://worldipv6launch.org
### END SIGNATURE BLOCK ###

limmy
500 Command not understood
Posts: 4
Joined: 2019-08-20 11:27

Re: "Preserve timestamps of transferred files" option not working correctly

#4 Post by limmy » 2019-08-21 06:29

boco wrote:
2019-08-20 17:42
Unfortunately, timeout on the Synology FTP server can be set to 2 hours tops (7200 secs).

As a workaround, repeat the transfers with "Resume". It will not transfer a single Byte (as the files exist) but set timestamps nonetheless. Note: If support for FTP ASCII transfers is enabled on the Synology device, this method will not work for text files.
1.
Thank you for the reply. The timeout setting was set at 300 on my server, so I increased it to 1 hour.
This change in the setting seems to solve the problem.

2.
Unfortunately, the "Resume" does not change the timestamp in my case. It simply skips and leaves the timestamp of downloaded file unchanged. Please let me know if there is an option that enables updating the timestamps.

limmy
500 Command not understood
Posts: 4
Joined: 2019-08-20 11:27

Re: "Preserve timestamps of transferred files" option not working correctly

#5 Post by limmy » 2019-08-21 06:41

botg wrote:
2019-08-20 16:44
Please post a log of such a download.
Status: Resolving address of MYSERVER.COM
Status: Connecting to 111.MYSERVER.IP:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Directory listing of "/FILE_DIRECTORY" successful
Status: Resolving address of MYSERVER.COM
Status: Connecting to 111.MYSERVER.IP:21...
Status: Resolving address of MYSERVER.COM
Status: Connecting to 111.MYSERVER.IP:21...
Status: Connection established, waiting for welcome message...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Initializing TLS...
Status: Verifying certificate...
Status: Verifying certificate...
Status: TLS connection established.
Status: TLS connection established.
Status: Logged in
Status: Starting download of /FILE_DIRECTORY/ONE_LARGE_FILE.zip
Status: Logged in
Status: Starting download of /FILE_DIRECTORY/TWO_LARGE_FILE.zip
Status: Disconnected from server: ECONNABORTED - Connection aborted
Command: CWD /FILE_DIRECTORY
Response: 250 CWD command successful.
Command: PWD
Response: 257 "/FILE_DIRECTORY" is current directory.
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode (111.MYSERVER.IP)
Command: RETR ONE_LARGE_FILE.zip
Response: 150 Opening BINARY mode SSL data connection for 'ONE_LARGE_FILE.zip' (2571609009 bytes).
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: File transfer failed after transferring 2,571,609,009 bytes in 901 seconds
Status: Disconnected from server


This is the log. I couldn't replicate the symptom I described while downloading two large files (one fails to update timestamp while the other succeeds) after I changed several settings on client side and server side. However, here is what happens when preserving timestamp fails. Once a transfer of a large file is complete, that is when network traffic drops to near zero, FileZilla client hangs for a while. The client is responsive, but the file download status stays at 100% for a minute or two without completing the download. After several minutes of pause, "Status: Disconnected from server: ECONNABORTED - Connection aborted" part of the log appears. I don't think this has to do with the speed limit of HDD because I tried the same on my SSD and I get the same result. The log shows that the file transfer has failed, but the content of the file is intact, and I was able to use the file. The only failure that I can notice is the failure to update the timestamp.

User avatar
botg
Site Admin
Posts: 32321
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: "Preserve timestamps of transferred files" option not working correctly

#6 Post by botg » 2019-08-25 07:19

Yup, that's a violation of REQ-5 from RFC 5382:
If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.

limmy
500 Command not understood
Posts: 4
Joined: 2019-08-20 11:27

Re: "Preserve timestamps of transferred files" option not working correctly

#7 Post by limmy » 2019-08-30 06:42

botg wrote:
2019-08-25 07:19
Yup, that's a violation of REQ-5 from RFC 5382:
If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
At first glance, I didn't understand what your comment was about. But after some searching, I began to suspect that my router (connected to my synology server) is secretly closing active connections without telling my client or server after approximately 5 minutes.

Therefore, I am experiencing the same problem seen in the following threads. That is, there is a long wait until the download finishes.
viewtopic.php?t=21246
viewtopic.php?t=33597

Nevertheless, preserving timestamps works despite the presumed closed connection after a long wait (if I set my server timeout long enough, in my case I set it to one hour). So, it seems that there is a process where closed connection can be recovered, but the client does not try to recover it until it waits about 10 minutes.

Here is what I experienced:
Downloading a 3GB file took 6 minutes (seen in the queued files window, the progress bar was at 100%),
but the client did not finish downloading for additional 10 minutes.
The relevant log is attached below.

14:22:57 Status: Verifying certificate...
14:22:57 Status: TLS connection established.
14:22:58 Status: Logged in
14:22:58 Status: Starting download of /FILE_DIRECTORY/ONE_LARGE_FILE.zip
14:22:58 Status: Retrieving directory listing of "/FILE_DIRECTORY"...
14:38:33 Status: File transfer successful, transferred 3,418,362,732 bytes in 935 seconds << the download was finished around 14:29, but it waited 10 minutes before finishing
14:38:33 Status: Retrieving directory listing of "/FILE_DIRECTORY"...
14:38:33 Status: Directory listing of "/FILE_DIRECTORY" successful
14:39:33 Status: Disconnected from server


I understand that my router maybe at fault here (not following the rules I guess). But would there be a chance that FileZilla cilent is configured to be dummy proof?

User avatar
botg
Site Admin
Posts: 32321
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: "Preserve timestamps of transferred files" option not working correctly

#8 Post by botg » 2019-08-30 07:08

Unfortunately there is little that can be done if a faulty router silently drops connection.

If you configure a short timeout in FileZilla it will however fail quicker instead of waiting for a possibly very long time.

Post Reply