Tag changes aren't being detected by my backup software

Some background: I am using CrashPlan for Small Business version 8.5.0.466. Part of my backup set includes all of my music files. However, because the original Date Created and Date Modified file properties are important to me (for file integrity, audit, and sorting purposes), when I use MP3tag to update ID3 information (add missing album art or tags, etc.) I always enable the built-in "Preserve file modification time when saving tags" setting that preserves those dates/times. However, my backup software doesn't detect any changes to the file when I use this setting in MP3tag, so it never overwrites the older version with the updated one.

I contacted CrashPlan technical support about this too, and here was their response:

"When we scan, we first look at the date modified and the file size to see if either has changed. If neither has changed, we hash a metadata block provided by the OS to try to see if there's any other differences. The OS decides when that block is updated and what it includes differs, so we don't have any control over that, but this is, at a high level, how we detect that a file has changed. Once we detect a file has changed, we include it in the backup to upload a new version.

In this behavior, both our file verification scan and the real time file watcher functionality behave similarly in how they decide to create new versions. So there's no other scan we can do that would catch a file that both of those features have deemed does not need a new version."

Are there other tags or file attributes (besides Date Modified) that I can use within MP3tag to force my updated files to be detected and seen by my backup software (or the OS)? I'm using Windows 10 Pro 64-bit. Thank you in advance for any ideas.

I suggest to rethink if this file dates are the correct way for "integrity, audit and sorting purposes". Maybe you introduce some new tags for your files for all this special needs?

Something like "Integrity-Date", "Audit-Date", "Sorting-Date" or whatever you want to name it?

That's an interesting idea. However, while that approach is feasible, it won't suit my needs because my other software won't be able to read or view those tags (they can only access vanilla file properties). And I would have to completely change my workflow and thousands of archived music files to match this new workflow. In a nutshell, I currently keep track of when the file was created, but I only allow other processes or actions (like changing a song's sound characteristics) to update the Date Modified field and prefer that simple tag editing or adding album art preserve the Date Modified.

But even this changes should modify the file size and CrashPlan's "metadata block provided by the OS". It is highly unlikely that a change inside the tags - especially the album art - let the file size unchanged.

If you use CrashPlan's "Code42 app", it should "constantly watches for new and changed files within your home directory with what we call the real-time file watcher." I assume, you can configure this file watcher to have a look for files outside your home directory too?

Yes, major album art changes seem to change the file size, but I notice simple (textual) tag edits or additions do not (can't explain why). Here are some screenshots comparing file properties for 2 files that are identical except one has a blank Album tag and the other has the Album tag information completed.

file01
file02

That is due to padding.
See e.g. this thread on the idea to increase the time by a second or so which would keep the general idea but also modify the data noticeably.

1 Like

Hmm, that might actually do the trick. But that feature request didn't get much traction since 2014. :frowning:

No.
But you might take up the idea and configure a tool that modifies the date with a command line for the suggested utility.

How about setting Archive Flag on File when modifying it.
Archive Bit is supposed to be used to be set on modification and reset after backup?

@MP3Freak_Peter thanks for the suggestion. I tried the archive, hidden, read flags and none worked (in getting the attention of the CrashPlan algorithm). Which is odd, because they claim it should:

I use "Attribute Changer" to bump the modification date one second: https://www.petges.lu/

It does the job, but it interrupts my workflow a little, so I sometimes forget to do it. Would be great if this could be done automatically within an Action group.

Thank you for that suggestion, using Attribute Changer can be a workaround for now (until this feature is added in the future?):