Opened 9 years ago
Closed 9 years ago
#10852 closed Bug report (fixed)
Inverse of timezone offset not applied when setting remote file timestamps
Reported by: | Howard Brown | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | ||
Component version: | 3.18.0 | Operating system type: | Windows |
Operating system version: | 8.1 |
Description
I want to transfers files up to my server that are actually newer than the version that is on the server. So I set the Preserve timestamp of transferred files and adjusted the server timezone offset to 3 hours, and enabled the directory comparison feature to use the compare modification time option.
To test this I created a new file on my computer in the root of the local directory that is synced with the server's site root directory and then refreshed the local window to show the new file.
The new file did not show with the yellow highlight.
I uploaded the new file and after it was copied to the server the version on the server had the same time as the local file plus three hours, but the file on the server was green highlighted indicating that it was newer than the version on my computer, which was just updated and except for the timezone difference was actually the same time.
I thought that the server timezone offset was supposed to take care of this kind of issue.
So two things:
1) Before the local file existed on the server, why wasn't it yellow highlighted in the local window?
2) After the local file was created/copied onto the server, why was it green highlighted in the server windows?
Thank you,
Howard Brown
P.S. Some programs allow you to highlight and copy the version and other information contained in the About pop-up window, which helps when filling out trouble reports. You have a 'send to clipboard' function which is nice, but being able to copy the individual fields is also very helpful.
Change History (5)
follow-up: 4 comment:1 by , 9 years ago
Summary: | With the server timezone offset to 3hr, after uploading a file to the server show the file as newer than the one just uploaded. → Inverse of timezone offset not applied when setting remote file timestamps |
---|
comment:2 by , 9 years ago
When I found out that the attachment size limit was smaller than the video I wanted to attach, I used FileZilla to send the video to my personal web-site, and the problem that I reported was essentially repeated, except that before the video was uploaded, the local copy did show as yellow highlighted. After uploading the server version as green highlighted, even though the server timezone offset set to that server, too.
Here is the video showing the first case:
http://home.earthlink.net/~howardb1/howardronaldbrownjr/FileZilla%20Client%20File%20Compare%20Newer%20Problem%202.mp4
Thank you,
Howard Brown
comment:3 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
A fix for this bug has been committed to the repository and will be available in the next version.
comment:4 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Replying to codesquid:
Summary changed from With the server timezone offset to 3hr, after uploading a file to
the server show the file as newer than the one just uploaded. to Inverse of timezone
offset not applied when setting remote file timestamps
Before sending the MFMT command (or its equivalent for SFTP) the timezone offset must
be subtracted from the intended timestamp.
Thanks for answering, but I don't understand what you mean by inverse of timezone and how would I do that?
Before reporting this issue I:
Subtracted my local time from the timezone of the server, it's three hours ahead of me, so I put 3 hours and 0 minutes in the server timezone offset.
After doing that, I enabled the preserve timestamp option.
Then I uploaded the file and saw that the uploaded file was highlighted in green.
Here is a link to a pdf showing the file versions on my local system and the server, and the timestamps that I'm talking about.
Thanks,
Howard Brown
comment:5 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Ah, I missed your second reply. Thanks.
I'm having trouble responding with this comment the system say that I've failed Chapta(sp?) and am likely spamming, but i don't see the Chapta thing anywhere on my screen.
Before sending the MFMT command (or its equivalent for SFTP) the timezone offset must be subtracted from the intended timestamp.