The file cannot be accessed error should have more options than just ''OK''

For example: if a user has among bunch of files two that have FILENAME like

Some_Song

and

Some__Song

i.e. with one and two pauses between the words and decides to remove all excess pauses [in this example replaced with the _ sign because of the limitations of this forum], then an action used for this will spit an error saying Cannot create file that already exists - plus give the choice of Abort, Retry and Ignore. And this is very user friendly as the whole operation can be either stopped or continued

But when for example a user wants to copy [whatever] TITLEs to FILENAMEs but happened to remove outside of Mp3tag even as little as one file from the its location, then an error will say that such file cannot be accessed - and forces user to "choose" only the OK option for the message box, which in turns stops the whole process at this missing file. And so we have an inconsistent behavior of Mp3tag


I often find myself in a situation when some of the that are listed in Mp3tag have just been consciously removed by me one way or another - and thus my workflow is stopped by this mandatory OK. If I could choose also Ignore, as I know what I am doing, then my modus operandi would remain efficient, becasue [in this second example] the renaming process would continue for other eligible FILENAMEs

The idea to rename files automatically is not new.
See e.g. this thread:

But I do not seek auto renaming feature at all

I wish Mp3tag would stop definitely interrupting my work when it stumbles upon a missing file. Of course Mp3tag should stop at such file - but then give me a choice to ignore this and move to another file down the list. It does such in case of the Cannot create file that already exists error - so it also should do similarly for the [...] cannot be accessed type situation

OK, apparently I was one step to far.
After you have been given the "option" to do something to the file, the logical consequence would be (I think) to get that automated.
Which would lead eventually to an automated renaming feature.
That is why I linked that thread.