Opened 16 years ago

Closed 15 years ago

#3869 closed Bug report (rejected)

Preserve timestamps of transferred files does not preserve for uploaded files

Reported by: u4forge Owned by:
Priority: normal Component: FileZilla Client
Keywords: preserve timestamp upload Cc:
Component version: Operating system type: Windows
Operating system version: XP Pro w SP3

Description

Windows platform, FileZilla client 3.1.3.1 of 2008.09.09

If a file is uploaded, the "Last Modified" time is the time of the upload, not the time of the original file. Toggling the setting of "Preserve timestamps...." does not affect the timestamp of the uploaded file. No problems appear in the log except that there is no attempt to reset the timestamp or otherwise protect the timestamp of the original file.

Uploading the same file to the same server/account using SmartFTP instead of FileZilla preserves the timestamp so the server-side is okay.
-m

Status: Resolving address of .....com
Status: Connecting to x.x.x.X:21...
Status: Connection established, waiting for welcome message...
Response: 220 Serv-U FTP Server v6.2 for WinSock ready...
Command: USER man
Response: 331 User name okay, need password.
Command: PASS
Response: 230 User logged in, proceed.
Status: Connected
Status: Starting upload of C:\Xfer\FTP-default\V2-35.exe
Command: CWD /beta/latest
Response: 250 Directory changed to /beta/latest
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode (x,x,x,X,19,1)
Command: STOR V2-35.exe
Response: 150 Opening BINARY mode data connection for V2-35.exe.
Response: 226-Maximum disk quota limited to 4194304 kBytes
Response: Used disk quota 0 kBytes, available 4194304 kBytes
Response: 226 Transfer complete.
Status: File transfer successful

Change History (3)

comment:1 by Tim Kosse, 16 years ago

Resolution: rejected
Status: newclosed

You need to upgrade to a better server that does support the MFMT command. Without that command, remote file times cannot be modified.

comment:2 by dcottingham, 15 years ago

Resolution: rejected
Status: closedreopened

This does actually appear to be a bug in the FileZilla client: I am using an FTP server that supports the MDTM command (Cerberus 3.00 beta 2). Using SmartFTP as the client (with the same server) the MDTM command is issued and works as expected. FileZilla does not issue an MDTM command (with "preserve timestamps" checked or unchecked). Bizarrely, I have sometimes seen an MDTM command in the logs on the server when a FileZilla client was used, but cannot reproduce them consistently, and moreover the timestamps in the MDTM commands are when the file was accessed, rather than created or modified.

comment:3 by Tim Kosse, 15 years ago

Resolution: rejected
Status: reopenedclosed

Read the FTP specs. MDTM MUST NOT be used to set timestamps. The RFC is very clear on that, it even has an example for that.

You HAVE TO use MFMT to set file timestamps.

Note: See TracTickets for help on using tickets.