Bug?/FeatureRequest: Folders compared have DateModified updated on compare (not sync)

Get help for specific problems
Posts: 2
Joined: 13 Jan 2024

bcbigb

Simple to recreate:
1) Make two folders.
2) Add them to L/R in compare. (I went one further and forced dates to 1/1/11 to make changes obvious)
3) Hit Compare, both folders' Date Modified timestamps are updated to present (i.e. like unix "touch" cmd).

Desired Behavior:
Please have FFS not change anything in any of the folders until a sync is actually initiated. I think the program should be functionally read-only during Compare, as most would assume that is a non-destructive/inert operation.

Testing:
1) I've tried from 13.1 to 9.8 in case it was a change I had missed --> All affected.
2) I tried disabling "Fail Safe File Copy" in case it was also using the .ffs_tmp files to lock it for scanning and that was causing the DateModified timestamp updates --> No change, still updated.

What issues does this cause?
This means I've been updating reams of folders unintentionally for years now when I've only used FFS for comparisons/duplicate checks without ever initiating syncs. While I don't exclusively rely on date modified, not knowing I was unintentionally wiping the old dates out is going to cause issues when going over old projects I thought were untouched since their archive date.


Thanks for any help you can render... this program is excellent and I've charged clients of mine so I could donate in the past as it's great. This is just a surprising quirk that doesn't make intuitive sense to me and goes against what I see as a sort-of "do no harm" until changes are requested paradigm that it seems the rest of the program is designed under, so this stands out.
User avatar
Posts: 3606
Joined: 11 Jun 2019

xCSxXenon

FFS places a LOCK file in the root folder to provide a way for other FFS sessions to detect each other and prevent multiple syncs from occurring at the same time on the same location. The creation/deletion of this file is modifying the folder, thus changing the date. There is an advanced setting to prevent this locking.
https://freefilesync.org/manual.php?topic=expert-settings
"LockDirectoriesDuringSync"
I would disable locking and try again to see if that achieves what you are expecting. There may or may not be consequences from this change, which is why it isn't exposed in the GUI.
Posts: 2
Joined: 13 Jan 2024

bcbigb

Thank you, I actually knew about the locking files, but was blending together the ".ffs_tmp" and the ".ffs_lock" file and thus thought I was addressing it with "Fail Safe File Copy" when I wasn't... derp. This is exactly what I need and shouldn't cause any issues in my situation as I'm the only one ever using FFS in any of my environments. Per testing, it's no longer affecting the folder DateModified and is solved for my situation.

In the larger interest of possibly tightening things up per my original message, is there a reason it locks during Compare and not, as the "LockDirectoriesDuringSync" setting name suggests, only during Sync? I'd hazard a guess that it prevents certain issues or at least avoids corner/edge cases mid-compare (like someone deleting the folder it's reading) or something in that vein. If my speculation is incorrect and the lock files can be limited to Sync, I think that should be considered as I think it would make this behavior of FFS a bit more intuitive for most people.

Either way, thank you for your help.
User avatar
Posts: 2287
Joined: 22 Aug 2012

Plerry

During/based on the Compare of the initial FFS instance, FFS decides which sync actions should be performed later, during the sync phase.
A Compare performed by a second FFS instance on the (at least part of) the same location(s) is blissfully unaware of any impending sync actions of the initial FFS instance as they may occur in between or during the second instances Compare and Sync phase, and may therefore result in sync errors or inconsistencies.
(Note that such second FFS instance may even run on another machine than the initial FFS instance.)