"The content of the current directory may have changed" issue

How to reproduce such situation:

1] Turn a Column on for the _DIRECTORY and / or _FOLDERPATH

2] Load up to Mp3tag 3 files

3] Play one of the files

4] Select that file and one other - thus leaving the third one alone

5] Using right click menu option ''Move'' trying to relocate both files to another location

6] Press Skip when prompted [by the operating system] about the first file being in use by other process [of the audio player]

7] Wait for the second pop-up [by Mp3tag] that says The content of the current directory may have changed and choose Cancel

8] Notice that all three files still show the same location



And so the Windows 10 gives the user an ability to skip a file that is being used [thus unavailable for movement] - but Mp3tag in unable to keep track of file that was not used by other process [thus available for transfer] and which was successfully transferred? Why cannot Mp3tag notice that that second file was indeed moved - as it would if that one would stop its playback in third party software? I understand the idea behind The content of the current directory may have changed pop-up and the Do you want to reread the current directory? question. But if Mp3tag could just really notice a played file not being moved and that other file being moved, such workflow interrupting pop-up would be simply unnecessary. If the user presses Cancel at the first pop-up then it my opinion the user does not care about such file - thus there is no need to bother the user with a second pop-up


I see this explanation

but I do not understand what was fixed back then. Nothing, as this could not be changed at that time [because of then inner workings of Windows]? If yes- how about now? Its been 15 years since then

Maybe Mp3tag could just scan the original location of files for which the Move was used and also the destination folder - thus update only status for them; somewhat alike to when the user changes the _FILE_MOD_DATE parameter outside of Mp3tag, goes back to Mp3tag, highlights such changed file and instantly in that moment a new data for _FILE_MOD_DATE is loaded thus shown to the user, all of which happens without a progress bar being used. Because right Mp3tag [re]scans... I do not know what. Because or me it sometimes scans all of the folders from which files were loaded to Mp3tag, sometimes one of the folders from which zero files were selected and sometimes a folder, in which resides a file that I have pinned to my audio player icon on Taskbar - and that last case is a tell-tale sign that there is also some kind of a bug related to this

This could take a lot of time if not just 3 files had to be moved.
TBH: users the apparently randomly press buttons to move files, play them at the same time, then abort such actions and are unwilling to follow the kind advice to re-read the folder get only very little of my sympathy.

I do not want to bore to death anyone with explaining just why this happens very often in my workflow and why it is also virtually unavoidable in my modus operandi. But for comparison:

I have a huge action group that cleans various errors, mostly in my TITLEs and FILENAMEs. And Mp3tag does not have such issue like the above when trying to execute that action action of mine on an used [thus blocked] file: it allows to swiftly Ingnore without further interrupting my workflow. And what is more it only ignores the part of my actions that are only in regards to the FILENAME. And on top of that, if a file is plain missing [because I happened to load up a whole bunch of files but some time later deleted one of them outside of Mp3tag], then I get only one pop-up, than overall requires from me pressing only once OK

And so this, as I just proved, is also an inconsistent treatment of missing files by Mp3tag

One of the ways to argue about a function is "is it really necessary?".

OK, I note that apparently situations can be provoked which lead to the behaviour that has been described.
But as you rightly say:

which names the reason: it is your workflow which could easily be adapted so that the described situation does not appear (esp. as you know by now how to provoke it):
wait.
It is that simple.
Do not

do not

I find an attitude: "look I mess up my system and I expect the freeware MP3tag to take care of all my attempts to sabotage the execution" simply way out.
So, let's see what kind of priority a change in behaviour gets.

OK, I understand you arguments

But regardless of our opinions, we still have