File timestamp not updated in multi tag-tag

win 7
When updating multiple files at the same time with tag-tag, the file modified timestamp was not updated. The particular field I was changing was Title. The problem does NOT happen when a single Title field is manually edited. However, I now tried this again with a simpler case of tag-tag (so as to avoid messing up tons of files), and the modified time WAS updated. The only thing that may have caused this was that I toggled the "preserve file modification time..." checkbox from off - to checked - to back to off. I am not sure what the default is, but if it is checked then I previously unchecked it between restarts of the program. So, this could be an issue of initialization. This was for mp3 files.

However, in doing that I noticed a separate bug. Namely, when I performed an undo, the date stamp was not changed back to the original. It would be useful if it were.

Bug? I see at least 2 file changes which are recorded as I would expect.

In a new installation the modification date is not kept.

I'm not sure I understand your reply about a new installation, and I'm not sure you understand my report.

What I am reporting is as follows:

  1. Preserve file modification checkbox is NOT checked.
  2. A number of tag-tag replacements are made in bulk (title field).
  3. File modified date on those files has not been changed, as verified outside of MP3Tag, while the tags have been changed as intended, also verified outside of MP3Tag.
  4. I clicked the preserve box, verified that it then preserves the timestamp.
  5. I unclicked the preserve box. Now it changes the timestamp as expected with similar title modifications.

I am not sure if you are saying the install state of that check box is checked or unchecked. My only reason for mentioning that is that I was unsure whether I had modified it in a previous startup of the program, which info might be useful in debugging.

Now, regarding the "bug" of undo not undoing the modification time.

From the point of view of the filesystem, the file was changed, then changed again. Therefore the timestamp is valid.

However, from the point of view of the program and the user the file should have been reverted to its state before any changes were made. Part of the state of the file is the modification time. In view of the fact that there is a checkbox to prevent changing the timestamp even if the file is changed it seems that at least some users would like the timestamp to be preserved when the file is left UNchanged.

also I should mention that I am using 64 bit version of win 7.

I still see that slightly different: if you decide not to change the modification date then an "undo" would also keep the original date.
If you have decided to let the OS do what it does, you see that change in the shape of the modified date...
I think the different point of views are clear now. We'll see what the future brings.