Enhancement Request: Option not to set "Date Modified"

[antonyupward]

Hi,

Overall @Dijji loving this "missing" functionality for Windows / Explorer - thank-you.

One surprise: when changing meta-data about the file (a tag or comment), the "Date Modified" for the file is changed.

Since Date Modified is also meta-data about the file, I didn't expect this.

For example, if you change the name of a file (also metadata) the Date Modified isn't changed.

And indeed on non-Windows systems, I use (for example MacOS) setting meta-data about the files is not considered a change to the file itself.

Is there a possibility to have an option to set / not set the modified date when meta-data is changed?

And / or changing the default so date modified is not changed (to make the behaviour consistent in Windows and across other platforms)?

Many thanks for considering this idea

[Dijji]

This behaviour is coming from Windows itself: I never touch Date Modified.

Your observations do make sense. Renaming a file changes only the file table, without touching the file contents. However, File Meta stores meta data in the alternate stream, which is part of the file storage, and so regarded by Windows as a change to the file.

I imagine that it is possible to override this default behaviour by capturing and restoring Date Modified when writing meta data properties, but I'm reluctant to do so, partly for stability reasons, and partly because the behaviour would then be inconsistent with that of all other means of updating meta data for the file.

Dijji

[TuggyNE]

I'm considering setting up some sort of wrapper or other hack, since for my primary usage of this extension it's quite inconvenient to have date metadata disrupted at all. I don't like to suggest adding options to software, but perhaps this is a good case for that?

For that matter, I just tested Windows' approach to downloaded file tainting, which uses its ADS to mark its origin as downloaded. Unblocking a file from its properties page, which rewrites an ADS, doesn't change its timestamps. So perhaps this would actually be consistent with Windows after all even if the API for it doesn't expose the behavior natively.