"Overwrite if newer" when date/time equal

[giomach]

On uploading, "Overwrite if newer" fires when date/time
of local and remote files is equal. I would like it to fire
only when the local file is newer. Win95, FileZilla 2.2.9,
sftp connection.

[giomach]

Screen shot of FileZilla; OK causes file to transfer

[giomach]

CoreFTP screen shot: Overwrite if Newer correctly does not transfer file

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I can confirm that this problem happens in XP also.

If you try to reproduce the problem, note that the local
(Windows) file to be uploaded should have a timestamp
containing a NON-ZERO number of seconds.

Here is a "worked example". Suppose the local file has a
timestamp of 4h 16m 8s. I upload it to www.smo.uhi.ac.uk
using a client which preserves the timestamp (Core FTP).
Most programs now show the remote timestamp on the
(probably unix) server as 4h 16m, or even 4h 16m 0s,
suggesting that it has been truncated to the minute by the
server during upload.

At some later time, with the local file not changed, we use
FileZilla to upload it again, applying the "overwrite if newer"
condition. We want the condition to prevent it being
transferred, by finding that the timestamps are the same and
therefore it is "not newer". But FileZilla transfers it.

If the remote timestamp is 4h 16m, and the local timestamp is
4h 16m 8s, a careless comparison of these might decide that
the local file was indeed newer (by 8 seconds). I don't know
if this is what is happening with FileZilla, but the better thing
is to truncate the local timestamp to 4h 16m before
comparing, just as it was truncated by the server during the
original upload. The truncated local timestamp required is
already available to FileZilla, displayed in the "File already
exists" dialog.

(I assumed that the remote timestamp is truncated to the
minute, but there is one program, WinSCP, which manages to
display remote timestamps on my server to the second, not
giving the seconds as zero but apparently correctly).

[giomach]

I do not know why my last comment was sent more than
once. Sorry!

[Tim Kosse]

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).