Linux OS (Ubunu 22.4 used actually) is causing an overwite of the last access timestamp at copy and move in some cases.
Free File sync unfortunately does not use the protected mode copy and move that prevents it,
In these cases all time stamps used are overwrritten and set to the time of copy / move
Synchronized directories with destroyed time stamps can't be use to compare on timestamps afterwards.
Being sure that the files with equal length are the same afterwards, always the binary compare must be done that in many cases takes prohibility long time to run.
Also a quit manual sorting out on datefiles for estimating of the usefull or relevance of different lenth versions can't be done any more with that.
This limitation renders it in many cases to being non usable
.
Is there a work-around available to force free file sync not to do this?
Timestamp handling, overwiting in Linux
- Posts: 3
- Joined: 26 Sep 2025
-
- Posts: 2982
- Joined: 22 Aug 2012
It seems you use the Mirror sync variant and in your Sync Settings (F8) do not have "Use database file to detect changes" checkmarked.
If you would, and Ubuntu 22.4 has stable file IDs, you should not have any problem.
If you can not use the database, have reasons not to use it, or Ubuntu 22.4 does not have stable file IDs, consider changing to the Update sync variant.
If the right side file is considered "newer", no left-to-right sync action is then proposed or will take place.
If the left-side file is modified, it will be newer than the date of the previously synced right side file, and hence the left-side modified file will be synced left-to-right.
However, in the Update sync variant files that are deleted left-side, will not get deleted right-side.
If this last aspect of the Update sync variant does not suit you, you can define a Custom sync variant.
• For the Difference category "Item exists left-side only" select the Action "Copy new item to the right" (right pointing green arrow with a + sign). (Identical to Mirror and Update)
• For the Difference category "Left side is newer" select the Action "Update right item" (right pointing green arrow without a + sign). (Identical to Mirror and Update)
• For the Difference category "Right side is newer" select the Action "Do nothing" (gray = sign). (Identical to Update)
• For the Difference category "Item exists right-side only" select the Action "Delete right item" (green trash can with red minus sign). (Identical to Mirror)
If you would, and Ubuntu 22.4 has stable file IDs, you should not have any problem.
If you can not use the database, have reasons not to use it, or Ubuntu 22.4 does not have stable file IDs, consider changing to the Update sync variant.
If the right side file is considered "newer", no left-to-right sync action is then proposed or will take place.
If the left-side file is modified, it will be newer than the date of the previously synced right side file, and hence the left-side modified file will be synced left-to-right.
However, in the Update sync variant files that are deleted left-side, will not get deleted right-side.
If this last aspect of the Update sync variant does not suit you, you can define a Custom sync variant.
• For the Difference category "Item exists left-side only" select the Action "Copy new item to the right" (right pointing green arrow with a + sign). (Identical to Mirror and Update)
• For the Difference category "Left side is newer" select the Action "Update right item" (right pointing green arrow without a + sign). (Identical to Mirror and Update)
• For the Difference category "Right side is newer" select the Action "Do nothing" (gray = sign). (Identical to Update)
• For the Difference category "Item exists right-side only" select the Action "Delete right item" (green trash can with red minus sign). (Identical to Mirror)
- Posts: 3
- Joined: 26 Sep 2025
Thanks you for you explicit and detailed explanation and handling proposal.
You concentrated on the database use, in linux the protected .syc.fssb file, that to me seems to be standard use, and is also used by me, also in the windows version. To this short after next follwing.
The problem I talk about is not related with that, it's the problem that at excetung the sync, by copying the file from source to target, in Windows the used used OS service does this copy WITH taking over all timestamps (last access, last changed, creation time)
cp -p persistent copy stetting in Linux:
In (Ubuntu) Linux (as used by the used Mint 22) however the used default copy service REWRITES the last access time (an all otherstamp) with the time of the copying, it thinks it is a new creation, if it is moved over different paths.
In your code a special handling must be added /changed to get in this copy file setting the original time form the source. Effectively this is a change from cp call, to cp -p call, for persistent copy mode.
This will than go in addition to the correct file user/owning right setting passing - which is done usually automatically using this Linux OS copy service.
If this is done on the result, the 'compare on time' can be used furtheron, as the used last changed time setting is kept and not destoyed with the copying in.
Database items:
The database file seems to be standard used and locked at LInux and at Windows use, at least I always had it, so also in my case.
The use of .ffs datbase file IS causing sometimes resync problem on NAS if used changing from one OS access to another (which is really asking do trouble), and using Freesync on both of them, a thing that everybody who runs this jazz should realize.
I had some cases where resynce did not response, not starting the rebuild of the .sync.ffsb file, , having to manually erase this file, to force it to do a clean rescan and build. Perhaps there is a program option for that, that I oversaw.
Also it may be annoying that after heavy use of freesync lot of ffs file corpses get lying around, often protected and not direwct erasable.
This however requiers often a change to admin access (Windows) / root level (sudo) access to get rid of it.
In malconfigured situtations, using alternative acces, again in linux, this may even run further group / owner blocking on this file - also causing the rescans not to work properly, making the erase the more an expert case, most handy on CLI level.
Thanks again for your extensive response and explantions.
You concentrated on the database use, in linux the protected .syc.fssb file, that to me seems to be standard use, and is also used by me, also in the windows version. To this short after next follwing.
The problem I talk about is not related with that, it's the problem that at excetung the sync, by copying the file from source to target, in Windows the used used OS service does this copy WITH taking over all timestamps (last access, last changed, creation time)
cp -p persistent copy stetting in Linux:
In (Ubuntu) Linux (as used by the used Mint 22) however the used default copy service REWRITES the last access time (an all otherstamp) with the time of the copying, it thinks it is a new creation, if it is moved over different paths.
In your code a special handling must be added /changed to get in this copy file setting the original time form the source. Effectively this is a change from cp call, to cp -p call, for persistent copy mode.
This will than go in addition to the correct file user/owning right setting passing - which is done usually automatically using this Linux OS copy service.
If this is done on the result, the 'compare on time' can be used furtheron, as the used last changed time setting is kept and not destoyed with the copying in.
Database items:
The database file seems to be standard used and locked at LInux and at Windows use, at least I always had it, so also in my case.
The use of .ffs datbase file IS causing sometimes resync problem on NAS if used changing from one OS access to another (which is really asking do trouble), and using Freesync on both of them, a thing that everybody who runs this jazz should realize.
I had some cases where resynce did not response, not starting the rebuild of the .sync.ffsb file, , having to manually erase this file, to force it to do a clean rescan and build. Perhaps there is a program option for that, that I oversaw.
Also it may be annoying that after heavy use of freesync lot of ffs file corpses get lying around, often protected and not direwct erasable.
This however requiers often a change to admin access (Windows) / root level (sudo) access to get rid of it.
In malconfigured situtations, using alternative acces, again in linux, this may even run further group / owner blocking on this file - also causing the rescans not to work properly, making the erase the more an expert case, most handy on CLI level.
Thanks again for your extensive response and explantions.
- Posts: 1223
- Joined: 8 May 2006
> overwite of the last access timestamp at copy and move in some cases
In what cases does this occur?
(In what case does it not occur?)
If FFS were not maintaining date on copy on Linux systems, I'd think there would be general outcry that FFS 'Time & Size' compare is blowing up on Linux, yet I don't recall that.
Default of cp, on all UNIX/Linux/Windows, will set times to current (AFAIK).
(You could set an alias or similar to add -p.)
In what cases does this occur?
(In what case does it not occur?)
If FFS were not maintaining date on copy on Linux systems, I'd think there would be general outcry that FFS 'Time & Size' compare is blowing up on Linux, yet I don't recall that.
Default of cp, on all UNIX/Linux/Windows, will set times to current (AFAIK).
(You could set an alias or similar to add -p.)
- Posts: 14
- Joined: 20 Oct 2016
What is the importance of last access time in linux? I thought it was customary to disable that with noatime in the fstab file. It's commonly recommended to do that to reduce wear on ssds (and increase performance of older hardware). Some distros (MX Linux, Linux Lite) install with noatime by default. I've never heard anyone complain about that.
Is it freefs updating the time, or linux os doing it because you don't have noatime?
Is it freefs updating the time, or linux os doing it because you don't have noatime?
