Hi everyone,
I'm a long user of FFS and absolutely love it !
My setup :
- macOS Sonoma 14.5 and macOS Big Sur 11.7.10
- FreeFileSync 13.6
- Synchronise from Mac's internal drive to external SSD drive. I have job (see attachments) for that given source (aka left) & target (aka right) are always the same. The mirroring job exists since may 2020 and worked flawlessly ever since.
I wanted to refresh my external (SSD) and noticed the target FOLDERS 'date modification' timestamp is reflecting the synchronisation time.
This only occurs when files are modified inside the folder tree (modified file can reside either in one or several levels below the root folder). The whole folder tree that is changed.
The folder's creation timestamp is correctly reflecting the source timestamp - work as desired.
All other target FILES are reflecting the source timestamp (creation, modified) - works as desired.
Given my confidence in FFS, I was sceptical about my findings and wanted to exclude the macOS layer.
On both machines (Sonoma and Big Sur), I used rsync (command line) to replicate the FFS job.
It gave me the expected result: source and target were fully synchronised - modification date are equal on both sides.
I returned to FFS after rsync, and reran the FFS job which didn’t identified any required synchronisation - as expected.
Sorry for the lengthy note, but believed I have another issue than those found on your forum.
Looking forward for a solution.
Folder's modification timestamp changed
- Posts: 5
- Joined: 21 Jun 2024
- Attachments
-
- Synchronisation.jpg (215.55 KiB) Viewed 254 times
-
- Filter.jpg (175.69 KiB) Viewed 254 times
-
- Comparison.jpg (195.98 KiB) Viewed 254 times
- Posts: 5
- Joined: 21 Jun 2024
Hi,
I'm trying to refine the root-cause, and could identify the issue coming from the "Compare" action either directly (Compare - F5) or via "Synchronise - F9" directly.
It changes actually the SOURCE and TARGET folder's 'modification' timestamp.
Tested on macOS Sonoma + Big Sur both on X86_64 and Sonoma 14.5 on Arm64, as well as in Windows 10 and Windows 11.
I even "downgraded" FFS, all the way back to FFS v11.29.
Same effects as described above.
Hence this might be a long lasting bug.
I don't expect FFS to change anything unless I hit "Synchronise".
Using rsync on command-line for now... not fun !
Looking forward for a fix.
Regards
I'm trying to refine the root-cause, and could identify the issue coming from the "Compare" action either directly (Compare - F5) or via "Synchronise - F9" directly.
It changes actually the SOURCE and TARGET folder's 'modification' timestamp.
Tested on macOS Sonoma + Big Sur both on X86_64 and Sonoma 14.5 on Arm64, as well as in Windows 10 and Windows 11.
I even "downgraded" FFS, all the way back to FFS v11.29.
Same effects as described above.
Hence this might be a long lasting bug.
I don't expect FFS to change anything unless I hit "Synchronise".
Using rsync on command-line for now... not fun !
Looking forward for a fix.
Regards
-
- Site Admin
- Posts: 7156
- Joined: 9 Dec 2007
It's the creation of sync.ffs_lock files
"LockDirectoriesDuringSync": https://freefilesync.org/manual.php?topic=expert-settings
"LockDirectoriesDuringSync": https://freefilesync.org/manual.php?topic=expert-settings
- Posts: 5
- Joined: 21 Jun 2024
Thanks.
Although, the target folder's modified timestamp is changed according to synchronisation timestamp and
NOT the source folder's timestamp !
NB: rsync does adjusts target folder's timestamp to reflect source timestamps.
Any fix for that ?
Although, the target folder's modified timestamp is changed according to synchronisation timestamp and
NOT the source folder's timestamp !
NB: rsync does adjusts target folder's timestamp to reflect source timestamps.
Any fix for that ?