[F] mp3tag 2.80 moves files when they get renamed in a path containing a folder name ending with unicode whitespaces (e.g. U+2000)

I'm using unicode whitespaces like "U+2006 (8198)" as last sign for folders of bands like "R.E.M." to have the "." as the last visible sign.

If I use mp3tag's converter to rename files in a folder like "R.E.M. " (which has an invisible unicode sign after R.E.M.!) or in one of its subfolders, then mp3tag will move the renamed files to a newly created folder "R.E.M" or a subfolder of this folder.

For Example:

Files from

C:\R.E.M. \Monster

are moved to a new folder called

C:\R.E.M\Monster

when mp3tag renames them.

This bug can be reproduced with other whitespaces like U+2006 from this list:

https://de.wikipedia.org/wiki/Unicodeblock_...e_Interpunktion

See also:

https://en.wikipedia.org/wiki/Whitespace_character

If these whitespaces are used in the "middle" of a folder name like "R.E.M. 1", instead, mp3tag doesn't have/create any problems.

/t/18382/1

<_<

I also for the longest time was using some variations of space, than I was only able to paste at the and of folder with the usage of ACDSee 3.1 graphics files viewer / handler. But a couple of years back I have finally started to cope with this issue by the means of adding an

 '

sign at the end of the name of the band like than; but only in the folder [and not in the tag fields]

So an R.E.M.
would become R.E.M. 'with an ordinary space to indicate that it is not a part of the "original" name

And I do now like this because other pieces of software also can have similar issues. Mp3tag maybe safe now in regards to such a dot, but why not error proof folders for all of them; all of the future software that you might use in time to come, be it for tagging, burning or moving of such folders?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.