The general AudioFileWriter behavior is, that a temp file is created with the new contents, the original file is moved out of the way and then the temp file is moved in its place. This has the advantage that a copy operation may be avoided, if both the temp file and the original file live in the same filesystem.
Unfortunately, this behavior creates a completely new file. Some applications actually have the capability of remembering the file identity (i.e. the inode on Unix and fileIndex on Windows). These applications are confused, when the file identity suddenly changes.
The proposed fix allows the user to simply write over the existing original file instead of moving it out of the way and replacing it with the temp file. This preserves the file's identity.
The new behavior can be turned on/off via a switch in TagOptionSingleton, as it's probably not desirable for everyone. By default it is turned off.
The pull request also contains a small addition for the default behavior: If possible, the creation date is adjusted to mirror the original file. This does not work on all file systems, but fails silently (with a log message), if it does not.
Great I never thought of doing it this way. Im aware of the problem which is one reason why I have moved most formats to now use AudioFileWriter2 which does not do it this way, it just makes changes to the original file so doesnt change the creation date either. But your method is a good (possibly interim) solution for those formats we have not converted and I think it should be the default, Ill review it properly as soon as I can.
The transactional thing was the original idea but it doesn't work well, too often we end up with tmp files remaining and user permissions sometimes allow editing files but not creating new ones that causes issues so I abandoned the transactional idea when I moved over to AudioFileWriter2, Will merge in.
The tests use TagOptionSingleton.getInstance().setPreserveFileIdentity(true); for some situations and simply the default for others, assuming that the default is false.
By setting the default for preserveFileIdentity to true you broke an implicit assumption.
Guess you already have it fixed, right?
No it wasn't that, and it worked on my Windows machine only failed on drone.io but then i realized testFileIdentity() doesn't run on WIndows.
I have found the problem the new creationtime was a couple of seconds out from the oldcreationtime that was causing the failure, Ive changed the test to have an allowance of 3 seconds