I was trying to rename some FLAC files as I normally would, and I received the following:
File "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\13-dashboard_confessional-get_me_right.flac" cannot be renamed to "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\Get Me Right.flac".
Cannot create a file when that file already exists.
File "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\14-dashboard_confessional-until_morning.flac" cannot be renamed to "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\Until Morning.flac".
Cannot create a file when that file already exists.
File "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\15-dashboard_confessional-everybody_learns_from_disaster.flac" cannot be renamed to "K:\SAB DLs\Dashboard Confessional-Alter The Ending-Deluxe Edition-16BIT-WEB-FLAC-2009-VEXED\Everybody Learns From Disaster.flac".
For a proper analysis it would require information about the applied function with all its parameters, preferably shown with screenshots, all the details about the sample file and also a screenshot of the target location.
Neither of these is accurate. I have run this rename uncountable times from the same root folder.
Also, I reran the rename function shortly after, and it went through successfully, so it must have been a bug in the software. If the issue persists with a different set of files, I will update, but at this point I have no further information to offer.
Your conclusion makes no sense. Bugs don't heal themselves, ever. Only the developer can do that.
Instead of jumping to conclusions without evidence, why not provide full details as requested by @LyricsLover and @ohrenkino? Then maybe you can discover what really happened.
My conclusion makes perfect sense. What doesn't make sense is you jumping into this telling me to provide details that I cannot possibly provide. I literally stated it worked when i tried the exact same process again, as it has uncountable times in the past. You can see from my original post that the filenames are not the same, and it is writing to the same location, so the file does not already exist.
Curb your attitude. Bugs can present themselves in all manner of different scenarios out of the blue. But here, have a screenshot of this complex rename function...
Maybe next time instead of copping an attitude with someone who points out an issue, have a cup of tea, settle yourself, and contemplate before hitting "Reply".
To be considered an Mp3tag bug, a problem must be reproducible. But you say that your renaming now works as expected, even though the software hasn't changed. And you are adamant that your procedure is always exactly the same.
All that tells me that this is very unlikely to be an Mp3tag bug.
It is quite possible that some other program other than mp3tag had access to this same folder, perhaps a player or library manager. If so the OS may have locked out change access at that time.
Without making any other software changes to mp3tag but getting the expected results the second time, it is unlikely to have been a bug. Especially if you have run the same action in the past and not had any issues either. A bug would usually be a repeatable and persistent problem. I'd say chalk it up to nothing more than unusual. If it does occur again, try to get as much detail captured as possible and share that for further analysis.
Such problems often occur when consecutive actions (action groups) are carried out, sometimes made worse by the fact that these actions in action groups are not necessarily carried out in the order in the action group.
It can happen, for example, that files are renamed according to tag contents at a time of execution, which actually leads to a collision in the file name.
This indicates, especially if error messages only occur sporadically, that it is not the content of the individual action that is responsible for the error, but rather the state of the files being processed at that time.
Such error messages (file names already exist) also occur again and again with actions that I carry out routinely and which are otherwise always carried out without problems. In every case, however, I was able to identify a file that actually existed at the time the respective file renaming was carried out as the cause.
The simplest situation would be if a file with this name already existed in the respective folder before the action was carried out. In addition, this situation can occur when several marked files are processed consecutively by an action.
So it is not enough to just look at the actions and their format strings to investigate the error message. It is therefore necessary to take a closer look at the tag content of the files, the time of execution, etc.
