change of directory timestamps

[moto]

Hi,

I noticed something I wasn't expecting. When doing comparison between 2 directories (not even trying to synch yet), FreeFileSync updates timestamps of the source and destination directories to the current date/time.

I don't think this is desired behaviour, comparison shouldn't make any changes, in particular source directory should stay intact!

[xCSxXenon]

This is most likely because FFS uses a database file to track changes in a location. The file is read from and written to during a comparison/sync, thus the folder has been modified and the timestamp is updated. Disable "use database file to detect changes" to test this theory. You likely want to keep it on though, improves performance. But maybe your scenario absolutely requires keeping the timestamp intact.

[moto]

thanks for the quick response.

As I understand the DB is part of the synchronisation - at least it's where it can be configured. I changed it to 'mirror' just for the sake of testing which also disables 'use database file to detect changes' but it didn't make difference, unfortunately.

It's only top level directory timestamps that I select as source and destination that get date/time updated. Yes, I think it is crucial not to change anything especially on source side, as like everyone else I use timestamps to observe when directories where last changed, and the fact source dir gets changed as early as at comparison stage just messes it up

[Plerry]

Are you sure nothing is written in the top-level directories?
By default FFS writes a lock-file right at the start of a Comparison, and removes it after the sync is finished or FFS is closed in a regular fashion.
See the description of the LockDirectoriesDuringSync flag.

[moto]

ahh so that was this flag that made a difference - changing LockDirectoriesDuringSync to false left original directories timestamps. thank you!

creating hidden file by FFS would change directory timestamps - so that's the answer. however this would happen at the comparison stage already and file would be removed right away as well, at least on the Mac I have, so I didn't notice anything.

I wonder if this should've been set up as default at all, or if it was better to dynamically set if multiple jobs or network drive was detected OR perhaps good compromise would've been to restore original timestamp on directories after the compare/sync

[xCSxXenon]

To be honest, the need to keep that timestamp intact is incredibly rare. The positives that come with these features severely outweigh the consequences for 99.99% of users and uses.

as like everyone else I use timestamps to observe when directories where last changed

I don't use them. File modification times are infinitely more important and are actually what most, if not all, professional and hobbyist developers use in my experience. I can only speak to my experience and industry though ¯\_(ツ)_/¯