Date and time stamps

Get help for specific problems
Posts: 6
Joined: 23 Nov 2017

MikeRubin

I was having some issues with FFS, so I deleted all my files on the destination drive and re-mirrored them from the source drive. Unfortunately, the date and time stamps at destination reflect the copy time and date, not the time and date of last modification. Therefore, FFS now thinks that all the destination files are not identical to the origin files. As a result, it wants to perform the entire copy job (3.1tb of data!) all over again when I want it just to update the few files that changed. Then, I presume, it always will want to back up the entire database because the time and date stamps always will be newer at destination than origin.

Is there any way to configure FFS so that it copies over the time and date stamps of the original files? Thanks for any suggestions.
Posts: 4
Joined: 4 Dec 2017

loskexos

I have the same problem.

Seems to happen for me whenever a Fritzbox is the target.
All target files get timestamp of the copy operation, not the source file timestamp.
Happens regardless of ftp or smb as protocol and regardless of target volume FS is NTFS or ext3.
Does not happen when files are copied via windows explorer (smb) or winscp (ftp).
Same behaviour on two different installations and Fritzbox types.

A Synology NAS as target does not show this symptom.

Tried to upgrade (was on 9.2) - happens also with FFS 9.5.
Tried to downgrade. Does NOT happen with version 8.2 (edit: also not with 8.10)!
Posts: 6
Joined: 23 Nov 2017

MikeRubin

I think I solved this, actually. I had my backup drive connected directly to a USB port on my NAS because I did not have an unfilled USB port on my computer. I disconnected a printer cable and plugged the USB drive into my computer. Once I did this, FFS copied over the proper file timestamps, although the directory timestamps are the copy dates, which isn't a problem. Now, when I run an FFS backup, the previously-copied files are skipped once again and only the changed or added files are copied over (with proper file creation dates).

I hope you are able to resolve the issue, as well. It really made my life difficult until I stumbled into this solution.
Posts: 4
Joined: 4 Dec 2017

loskexos

Not sure I follow completely. You now have your drive connected via USB directly?

Then our problems had similar symptoms but very different cause it seems.

Looks like FFS is copying the file, then adjusting file attributes.
For a Fritzbox as NAS network target the attribute adjustment seems to be missing/uncompatible/failing since jump to version 9.x.
Posts: 6
Joined: 23 Nov 2017

MikeRubin

Not sure I follow completely. You now have your drive connected via USB directly? loskexos, 06 Dec 2017, 22:02
Yes, the USB drive now is connected to a USB 3.0 port on my Windows 10 computer. Previously, when I was having this problem, the same USB drive was connected to a USB 3.0 the on the NAS.

Hope you can get to the bottom of your issue.
Last edited by MikeRubin on 07 Dec 2017, 15:33, edited 1 time in total.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

All target files get timestamp of the copy operation, not the source file timestamp. loskexos, 04 Dec 2017, 20:15
And you see no warning message about failure to set time stamps in the log? (warning, not an error message)
Tried to upgrade (was on 9.2) - happens also with FFS 9.5.
Tried to downgrade. Does NOT happen with version 8.2 (edit: also not with 8.10)! loskexos, 04 Dec 2017, 20:15
If this issue really is triggered by recent changes, it should be easy to find. Are you able to narrow down since which FFS version exactly the time stamps fail to be copied?
Posts: 4
Joined: 4 Dec 2017

loskexos

Sorry for late reply, wanted to get some more beef for a response.

I've tried to reproduce by upgrading step by step through
each version starting from 8.10 and then testing.

All with SMB to target fritzbox with 2 different locations
(one USB stick formatted with ext3, another one formatted with NTFS).

And could not reproduce :(.

Then switched on ftp instead smb.

And noticed that already the comparison function now displayed everything as delta
that was already already synced via smb and unchanged since then.

Meaning:
Sync via SMB. Works fine. Compare - no delta.
Switch to ftp for same location: comparison identifies everything as different.
Some files show in target window (read through ftp) with 1 hour difference.
Others show with 1 am as change timestamp (correct date).
Looking at the folder via SMB shows everything with correct change timestamp.

Looks like reading access timestamp is going wrong somewhere.
Not sure if this is on freefilesync or fritzbox/NAS side.

Some more testing:
Looking at the folder via ftp (WinSCP) shows that the files having 1 hour
difference in FFS ftp comparison are showing with correct time with WinSCP
via ftp (although with HH:MM, no seconds).
This would point to FFS for interpreting the ftp response wrongly?
A problem with Timezone interpretation?
The files showing with 1 am in FFS ftp comparison do show without time
in WinSCP. I guess FFS is defaulting to 0 am plus the 1 hour misinterpretation
from above. The files have normal date and time on source.

Looks like something is also iffy on fritzbox/NAS side storing change time.

More testing shows:
Copying the folder via WinSCP using ftp produces all files with timestamp
of copy.

FFS Clean sync a folder pair using ftp shows these error messages:
Die Änderungszeit von "ftp://xxx.xxx.xxx.xxx/LEX_128G_black/TestFTP/Belt.b37d.ffs_tmp" kann nicht geschrieben werden. Server does not support the MFMT command.
Repeating the sync shows same message.

Looks like indeed the fritzbox/NAS ftp server implementation has a gap
that does not allow to adjust time (MFMT command).



Summary:
- ftp-write: Fritzbox/NAS ftp server cannot handle MFMT command used (and needed) by FFS
- ftp-read: FFS might be misinterpreting ftp responses regarding time from fritzbox/NAS,
or maybe another command is not handled (MDTM command ?)


All in all it seems a unfortunate restriction on Fritzbox ftp server implementation
as rootcause rather than FFS implementation.

PS:
Why using ftp:
less overhead, more stable throughput.
Allows to disable SMB access so SMB based Cryptotrojans won't be able to find and crypt the backup on network share.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

The problem is the FritzBox only implements rudimentary FTP. It does not support "MLST", so it's not possible to retrieve accurate file times. The response from the FritzBox looks like:
drwxrwxr-x 1 ftp ftp 2048 Jun 21 2013 Videos
-rw-rw-r-- 1 ftp ftp 6640 Dec  1 2011 FRITZ-NAS.txt
-rw-rw-rw- 1 ftp ftp 308 Dec 13 17:26 file.txt
Note that there is no time info for files older than 1 year and when time info exists, it's "local" time, whatever that means, only the FritzBox knows. In short, legacy FTP is a pretty crappy protocol. Newer FTP variants supporting MLST and MFMT fix most of the flaws, but for some reason, the old variants are much more widespread. Apparently because they are easier to implement.
Posts: 4
Joined: 4 Dec 2017

loskexos

I've contacted AVM (fritzbox manufacturer).
Support confirmed the restriction and submitted this as enhancement request to product management.
I hope for the best ;). Until then I'll stick with SMB.
Posts: 2
Joined: 26 Mar 2018

asaph


Meaning:
Sync via SMB. Works fine. Compare - no delta.
Switch to ftp for same location: comparison identifies everything as different.
Some files show in target window (read through ftp) with 1 hour difference.
Others show with 1 am as change timestamp (correct date).
Looking at the folder via SMB shows everything with correct change timestamp.

Looks like reading access timestamp is going wrong somewhere.
Not sure if this is on freefilesync or fritzbox/NAS side.

S loskexos, 12 Dec 2017, 21:22
My problem is since yesterday (begin of summertime in Germany) that all files in win10 tablet (on SD card)
are 1 hour younger than on a m2m drive (multi media network player intenso with SD card) .
e.g.:
1) win10 abc123.txt 20160501 17:17 m2m abc123.txt 20160501 16:17
2) win10 textf89.xls 20140201 02:00 m2m textf89.xls 20140201 01:00

in the moment I synchronize only new files from the left to the right site (vice versa).
But I cannot synchronize changed files, coz the system will synchronize all files because of the time lag of 1 hour btw. systenm win10 an m2m....

How can I fix this problem?


Greetings Andreas
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

My problem is since yesterday (begin of summertime in Germany) that all files in win10 tablet (on SD card)
are 1 hour younger than on a m2m drive (multi media network player intenso with SD card) . asaph, 26 Mar 2018, 07:37
https://freefilesync.org/manual.php?topic=daylight-saving-time
Posts: 1
Joined: 8 Oct 2020

GIOBIN

I've contacted AVM (fritzbox manufacturer).
Support confirmed the restriction and submitted this as enhancement request to product management.
I hope for the best ;). Until then I'll stick with SMB. loskexos, 15 Dec 2017, 16:52
It's incredible but after 3 years AVM didn't yet solve this serious ftp limitation. Files date is still sadly wrong. I use GoodSync, but Fritznas using ftp is totally unusable.