Synchronizing folders the modified dates change

Dopus 10.0.0.6

When I use synchronize, the folders in the right pane have their modified dates changed to present date, the file dates remain unchanged.
I would have thought both sides should be equal in all respects after synchronization.
Is this a bug or is there some way of synchronizing folders that I am missing?

File dates are meaningful and should be preserved.

Folder dates are rarely meaningful. Off the top of my head, I'm not sure if Opus tries to preserve them or not, but any change to the contents of the folder (e.g. creating, deleting or renaming a file) would bump the folder's timestamp.

Thanks reply Leo but I am somewhat confused.
If I copy a folder (D:/Temp1 to D:/Temp2) the timestamp of the folder is maintained
Settings are: Settings/Preferences/Copy Attributes are set to preserve the timestamps of copied files
If I synchronize a folder it is not
The reason I need the folder timestamp unchanged is that I have thousands of folders which are sorted by modified date

The sync tool thinks in terms of files, so that makes sense I guess. You could send in a feature request for it to copy the folder attributes as well (GPSoft Support link in my sig).

But keep in mind that if you're relying on folder timestamps, they'll change if you do anything that changes/adds/removes a file/folder name within those folders.

It's good to make a distinction between Creation and Modified date/times. For folders, the Creation date/time is permanent (for normal OS stuff) but the Modified date/time changes as Leo described.

-- Steve (up way too early)

Thanks Steve but not in this case

You will find that by using synchronization the folder creation time is also altered to present time and date

My opinion is that this is not how synchronization should work, but who am I to say :smiley:

Folder modification times are used by plenty of software as cheap tests for performing more expensive operations. Music rescans, software rebuilds, archiving, etc. These dates should be preserved.

If you've just copied the folder to somewhere else, the tools aren't going to know what it is anyway.

And they'd be better using the file timestamps, since the folder timestamps don't change if you modify an existing file's data, and do change if you create & delete some unrelated file, making the folder timestamps a curious thing to rely on for most (not all) operations.

But, as I said, anyone who wants this adding to the sync tool can request it via GPSoft Support (link in my sig).

Some quick-to-mind, real cases for you:

  1. J. River Media Center
    People routinely copy their music libraries to a new disk, and then within MC change the base path of the file names. Other software that shares that library doesn't want to see folder dates change... such as

  2. Logitech's Squeezebox Server
    which uses folder dates to trigger some meta-data rescans for new cover art files added to folders.

  3. Build systems that use relative path names (i.e. they don't have to be told about the parent directory change) within a build tree that use folder time stamps to indicate a set of productions are up to date.

Really, Leo, this may more common than you appear to understand. :slight_smile:

I'm not saying nothing uses the folder timestamps; I'm saying that most things that use them are being stupid and won't work very well. :slight_smile:

For example, how does the Squeezebox server know that some of the tags in the files in a directory haven't changed if the whole directory is skipped based on the directory timestamp? (The directory timestamp won't change if the tags on the files in the directory are changed.)

And how does it know about subdirectories, unless it scans the contents of each directory? (Changes to subdirs don't modify the parent's timestamp either.) If it does scan the contents of each directory it might as well use the real file timestamps instead of the unreliable folder timestamps.

Using the folder timestamps is usually a broken optimization.

But, sure, some things do use the timestamps. Nothing we can do about that. :slight_smile: So file those feature requests.

Really, it serves no purpose to arbitrarily label other software as broken, using broken optimizations, or whatever. That is a red herring argument, philosophical and arbitrary.

If the request to preserve timestamps of folders can reasonably be accommodated (and you get the feature requests submitted!), why not be as precise as possible in creating a synchronized sub-tree?

Did you read the last line of my reply?

I am not arguing against the change. I acknowledge that some tools (mis)use the timestamps and thus the change has merit.