FFS 5.10, Win XP
sync.ffs_lock is bumping source folder modified date/time?
I don't recall that happening in the past?
It's not really a bug, per se, except that when viewing my directories in my file manager, I'm kind of used to certain directories being in certain relative locations (when sorted by time, which is most often the case for me).
Now they are kind of "out of wack", in my mind.
Any way to do this without touching the directory date/time?
Perhaps push the date/time prior to setting sync.ffs_lock, then pop it afterwards.
Seeing something "pop to the top" is kind of an indicator to me that something has happened & when it happens in unexpected places, as it has now done, that prompts me to explore the cause.
Thanks.
sync.ffs_lock is touching source folder modified date/time
- Posts: 1037
- Joined: 8 May 2006
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
A folder modification time is changed each time a file or subdirectory is created or deleted. This is the same relation as for file modification time and file content.
- Posts: 1037
- Joined: 8 May 2006
I'll note, (Nirsoft's) FolderTimeUpdate.
See also, FFS: Preserving dates and times of directories
FolderTimeUpdate is a simple tool for Windows that scans all files and folders under the base folder you choose, and updates the 'Modified Time' of every folder according the latest modified time of the files stored in it.
This tool might be useful if, for example, you backup a cluster of folders and then restore them into another disk, but the backup program doesn't restore the original modified time of the folders.
See also, FFS: Preserving dates and times of directories
- Posts: 1037
- Joined: 8 May 2006
Could sync.ffs_lock store a directories existing timestamp (before any actions occur in the directory), then if no changes were made to the particular directory, restore the timestamp to existing, afterwards.
(Obviously, if there were any changes, the directory timestamp is expected to be touched.)
(Obviously, if there were any changes, the directory timestamp is expected to be touched.)
- Posts: 11
- Joined: 3 Sep 2020
therube -- that would be an excellent depth-first iterative approach if the program does indeed follow a depth-first algorithm. I'm not positive it does, but someone else can weigh in on that. It would be O(n) where n is the number of folders in the tree. Probably the minimum bounds you can have on this kind of problem.