Opened 15 years ago

Last modified 6 years ago

#775 closed Bug report

"Overwrite if newer" when date/time equal

Reported by: giomach Owned by:
Priority: normal Component: Other
Keywords: Cc: giomach, Tim Kosse
Component version: Operating system type:
Operating system version:

Description

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.

Attachments (2)

FileZilla.jpg (137.0 KB) - added by giomach 15 years ago.
Screen shot of FileZilla; OK causes file to transfer
CoreFTP.jpg (171.7 KB) - added by giomach 15 years ago.
CoreFTP screen shot: Overwrite if Newer correctly does not transfer file

Download all attachments as: .zip

Change History (13)

Changed 15 years ago by giomach

Attachment: FileZilla.jpg added

Screen shot of FileZilla; OK causes file to transfer

Changed 15 years ago by giomach

Attachment: CoreFTP.jpg added

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

comment:1 Changed 15 years ago by 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).

comment:2 Changed 15 years ago by 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).

comment:3 Changed 15 years ago by 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).

comment:4 Changed 15 years ago by 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).

comment:5 Changed 15 years ago by 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).

comment:6 Changed 15 years ago by 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).

comment:7 Changed 15 years ago by 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).

comment:8 Changed 15 years ago by 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).

comment:9 Changed 15 years ago by 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).

comment:10 Changed 15 years ago by giomach

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

comment:11 Changed 15 years ago by 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).

Note: See TracTickets for help on using tickets.