sync.ffs_lock is touching source folder modified date/time

Get help for specific problems
Posts: 943
Joined: 8 May 2006

therube

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.
User avatar
Site Admin
Posts: 7052
Joined: 9 Dec 2007

Zenju

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: 943
Joined: 8 May 2006

therube

I'll note, (Nirsoft's) FolderTimeUpdate.
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: 943
Joined: 8 May 2006

therube

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.)
Posts: 11
Joined: 3 Sep 2020

nilsonj

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.