Hi i try to use Freefilesync for FTP sync to my Cloud FTP server.
I found out that all the file download by Freefilesync will have modified time +8.
I did retest from different server and PC and come with the same issue.
This causing issue when we want to copy directly the upadated file to local server which later will be overwrite by file from Cloud at FTP server due to FreeFileSync assume cloud file is more newer.
Unfortunately we cannot use content comparison due to our indicator is the newer which same file will be keep updated either from cloud or to local server directly.
In addition i did test using filezilla and the simillar issue not happen. The modified time remain the same as the FTP push to FTP server.
I did also wireshark capture for both test using Filezilla and Freefilesync together with FEAT issue to server command screenshoot.
FTP Sync Transfer File Modified Time Advanced +8
- Posts: 3
- Joined: 10 Feb 2021
-
- Posts: 4867
- Joined: 11 Jun 2019
Interested in what Zenju can find out, but you could set a timeshift value to workaround that for now
- Posts: 3
- Joined: 10 Feb 2021
Hi XCSxXenon, thank you.. im using the timeshift also at first but seem for my use case scenario not much practicle due to the file at both side must have exact time(including minute) after consider timeshift(not tolerance).
My case they will have different time if we push updated file to local system but not at cloud system (with update mode from cloud to local system as primary flow). File will be always updated by FileFreeSync due to they assume they are different file(due to different time >minute/second).
I also try to edit the global configuration in the tolerance, but seem not the best option as the file still come out with +8 advanced time as we need to refer this as indicator when last someone push the file.
As for my usage application, it is okay to just recieve the file with modified time at sync time(current time). As we have batch scehdule for every 5min for comparison, so if new updated file coming the modified time not different much from actual time(if they sync with current time). However as they have +8 and sometime we need to push manualy the file to local system(due connectivty issue at cloud), this will become a problem and those files will always we overwrite.
Attached also another testing using filezilla, seem like filezilla will utilize FEAT and MDTM for the transfer.
Thank you.
My case they will have different time if we push updated file to local system but not at cloud system (with update mode from cloud to local system as primary flow). File will be always updated by FileFreeSync due to they assume they are different file(due to different time >minute/second).
I also try to edit the global configuration in the tolerance, but seem not the best option as the file still come out with +8 advanced time as we need to refer this as indicator when last someone push the file.
As for my usage application, it is okay to just recieve the file with modified time at sync time(current time). As we have batch scehdule for every 5min for comparison, so if new updated file coming the modified time not different much from actual time(if they sync with current time). However as they have +8 and sometime we need to push manualy the file to local system(due connectivty issue at cloud), this will become a problem and those files will always we overwrite.
Attached also another testing using filezilla, seem like filezilla will utilize FEAT and MDTM for the transfer.
Thank you.
-
- Posts: 2947
- Joined: 22 Aug 2012
I don't know which protocol FileZilla uses, but it is most likely not FTP.
Most (all?) FTP servers do not preserve file-dates when copying over files.
See e.g. here, item 4a)
Most (all?) FTP servers do not preserve file-dates when copying over files.
See e.g. here, item 4a)
-
- Site Admin
- Posts: 7506
- Joined: 9 Dec 2007
@hamzaniazni: Great feedback! I like the screenshots, FEAT response, and Wireshark logs! Hardly anything unclear about the problem!
The problem is that the FTP server doesn't support the MLSD command that is required to receive accurate file time information. So FFS has to fall back on "LIST", which is not accurate: e.g.
2. To make matters worse, the times are in server-local time zone. Which time zone that is, only the server knows, and it doesn't tell!
Problem 2 can be worked around via the MDTM command. This is what FileZilla is doing. It allows to more or less "guess"timate what the time zone offset is. This cannot be precise because of 1.
But even when 2 is more or less solved, problem 1 still makes such FTP servers more or less unsuitable for a "compare by time and size".
Problem 3: The server doesn't support the MFMT command, which means it's not possible (without more dirty hackery...) to set file modification times. This makes the server almost unsuitable for synchronization and backup (... and therefore almost worthless for any kind of serious work).
The "solution" is to not use old and broken FTP servers. I don't know why such old software is still in use, but apparently it is. If the Cloud provider is in control of the server, it's them who should be blamed.
The problem is that the FTP server doesn't support the MLSD command that is required to receive accurate file time information. So FFS has to fall back on "LIST", which is not accurate: e.g.
1. Notice that the file modification times only have minute precision for newer files, and are only precise to the day(!) for older dates. Newer ones also don't show the current year, which creates further ambiguity.drwxr-xr-x 1 root root 4096 Jan 10 11:58 version
-rwxr-xr-x 1 root root 1084 Sep 2 01:17 Unit Test.vcxproj.user
-rwxr-xr-x 1 1000 300 2217 Feb 28 2016 win32.manifest
lrwxr-xr-x 1 root root 18 Apr 26 15:17 Projects -> /mnt/hgfs/Projects
2. To make matters worse, the times are in server-local time zone. Which time zone that is, only the server knows, and it doesn't tell!
Problem 2 can be worked around via the MDTM command. This is what FileZilla is doing. It allows to more or less "guess"timate what the time zone offset is. This cannot be precise because of 1.
But even when 2 is more or less solved, problem 1 still makes such FTP servers more or less unsuitable for a "compare by time and size".
Problem 3: The server doesn't support the MFMT command, which means it's not possible (without more dirty hackery...) to set file modification times. This makes the server almost unsuitable for synchronization and backup (... and therefore almost worthless for any kind of serious work).
The "solution" is to not use old and broken FTP servers. I don't know why such old software is still in use, but apparently it is. If the Cloud provider is in control of the server, it's them who should be blamed.
:D The whole point of FileZilla is that it's an FTP client!I don't know which protocol FileZilla uses, but it is most likely not FTP. Plerry, 12 Feb 2021, 09:50
Maybe 80% of FTP servers do in fact return precise time information (MLSD) and also save modification times (MFMT). The thing is you only read/hear about the broken ones on forums.Most (all?) FTP servers do not preserve file-dates when copying over files. Plerry, 12 Feb 2021, 09:50
- Posts: 3
- Joined: 10 Feb 2021
Hi Zenju,
Thank you for quick reply and very rich in information. Really apriciate that and your time.
it is possible to know is there any possiblity for Freefilesync at least behave like Filezilla?
As for my usage application, we still can accept if the modification time become the current time(when file transfer happen/intvl of evry 5min to sync check) as right now it at +8 which not happen at filezilla.
It is possible to know where Filefreesync get +8 time different compre to the file at server while filezilla not doing so?
Thank you for quick reply and very rich in information. Really apriciate that and your time.
it is possible to know is there any possiblity for Freefilesync at least behave like Filezilla?
As for my usage application, we still can accept if the modification time become the current time(when file transfer happen/intvl of evry 5min to sync check) as right now it at +8 which not happen at filezilla.
It is possible to know where Filefreesync get +8 time different compre to the file at server while filezilla not doing so?
