Account for server & client time difference

[krobertson]

When target file exists, "Overwrite if source newer" is an excellent option, but its usefulness is degraded by time differences between server & client machines. Consider I'm on in EST and FTP Server is on PST, and I upload a file to Server at 5:00. Server accepts file and timestamps it as 2:00 (its local time). Now if I upload file again, FileZilla Client sees file as newer, always uploading the file even if there were no changes. Worse is if I'm PST and server is EST. I upload file at 2:00, server timestamps it as 5:00. Then if I soon change the file and re-upload my files (2:02) with this option, Client will not see this file as newer so it's not uploaded.

Client should account for local time differences between client and server machines, and it can do so automagically as follows. The first time during a session that this option is used, Client can upload a dummy file to the server, collect its timestamp from the server (getting the server's local time), then delete the file. It saves a "time skew" for the session, which is local time minus server time. Then when comparing dates for the "if newer" option, it adds the time skew to the dates for file on the server, to get the files' timestamps in local time.

In fact, you may even do this at the beginning of any session so that the Remove site files' Last modified dates are shown in local time.

[Alexander Schuch]

Which version of FileZilla are you using, and on which platform?

For some versions already, FileZilla tries to detect the time zone offset automatically by issuing an MDTM command on connect. Check your log for something like "Calculating timezone offset of server..." or "Timezone offsets: Server: 3600 seconds. Local: 7200 seconds. Difference: 3600 seconds.".

Furthermore, you can manually enter a different time zone offset for each Site Manager item.

Can you please explain how these time zone facilities fail for you (in the latest/most recent version of FileZilla)?

[krobertson]

Log shows no use of MDTM Command

[krobertson]

3.0.9.1 (the latest) built 2008-04-07 for Windows.

By "log" I assume you mean the running log in the interface, which I will attach. (Is there a relevant log file in the file system? I don't see one.) It shows MDTM only as a Response, to FEAT. It's not issued as a command.

Aha, now THAT I can use. Thanks! I was just using Quickconnect, which doesn't seem to have this option.
File Added: filezilla.log

[Alexander Schuch]

FileZilla doesn't (yet) log the log messages to a file - only to the message pane.

As far as I know, FileZilla needs a file in the home directory of your user account for the MDTM command to work. The home directory is the directory the FTP server sends you to when connecting to it. Is it possible that you do not have a file there but only directories?

[krobertson]

No, the home directory has files. And according to the log, FileZilla never issues an MDTM command. You can address this, but for my needs, going through the site manager instead of quickconnect has resolved my problem.

[Alexander Schuch]

This then might look like a bug, as to my knowledge, FileZilla is supposed to try to auto-detect the time offset.

[Tim Kosse]

The server is in violation to the FTP specifications. As defined in RFC 2389, the FEAT response has to use exactly one space before each listed feature. Your server uses 4 spaces as can be seen in the logs.

As such, FileZilla cannot detect support for the MDTM command and the automatic timezone detection fails.

Please switch to a proper server.

[Tim Kosse]

​http://filezilla-project.org/specs/rfc2389.txt

[krobertson]

Wish I could. The server is for a web hosting account with a MAJOR provider located in Arizona. I have no control over their server software. If you don't wish to make FZ Client flexible enough to deal with servers that deviate so superficially from the spec, that's your prerogative. ci-dev gave me a workaround. Cheers.