`Convert → Tag - Filename` behaves unexpectedly when folder name in path starts with space character

Support
1

Hello.

I know that using slashes in the format string can create folders, this is not about that.

Expected behaviour:
Using a format string that does not include any slashes renames files in place, no moving takes place, no folders are created.

Observed behaviour:
If any of the parent folders start with a space character, a new folder with the trimmed name is created (the name no longer starts with a space character) on the same level, together with the rest of its subfolder hierarchy, and the files are moved there while renaming.

Example:
I am frequently using a simple format string ($num(%track%,2). %title%) to rename downloaded files. The files are usually found in a path similar to: D:/Downloads/ Category/-- Subcategory --/Some random subfolder. Please notice that the ” Category” folder starts with a space.

The Convert → Tag - Filename action works correctly except for the fact that the renamed files are moved to D:/Downloads/Category/-- Subcategory --/Some random subfolder! Please note that the ”Category” folder no longer has a space at the beginning, and it's a newly created folder on the same level as the original ” Category” folder.

I hope it's clear and you will be able to reproduce the issue. Thank you for looking into this, and for your awesome work!

Cheers,
T

2

See here:

3

Maybe this Microsoft page helps too to understand

File and Folder names that begin or end with the ASCII Space (0x20) will be saved without these characters.
File and Folder names that end with the ASCII Period (0x2E) character will also be saved without this character.
All other trailing or leading whitespace characters are retained.

4

Thanks for the link. While I can understand Microsoft's position on the issue, their implementation is inconsistent and it actually makes thing worse for everybody.

For example, if I use Windows Explorer to rename a file in the aforementioned D:/Downloads/<space>Category/ folder, it renames it in place and it doesn't move it to D:/Downloads/<no space>Category/. So I don't think it's an unreasonable expectation that a file rename using Mp3Tag behaves the same.

But while my opinion is that it would be better to respect the user's path choice and never move files around for unclear and unexplained reasons, I understand why this is not actually a bug in Mp3Tag.

I now also know how to avoid getting bitten by this issue again, so thank you.

5

Thank you for your feedback.

I just wonder:
How do you create a foldername like this:
D:/Downloads/<space>Category/

If you try to create such a folder in the Windows File Explorer you can see that this is not possible. All three characters: the Slash / and the usual Backslash \ and the mentioned leading space will not be accepted by Microsofts own file and folder tool.

6

Yes, you are right, Windows Explorer strips away „illegal” characters. In this particular case, the folder was created a long time ago using macos (I'm dual booting a mac mini).

But I can also create folders named like that using the command prompt and something on the lines of:

d:\Downloads> mkdir " test folder with initial space"

(the quotes are the key), which then looks like this:

D:\Downloads\>dir
 Volume in drive D is Data
 Volume Serial Number is ****

 Directory of D:\Downloads

22/07/2024  15:12    <DIR>          .
24/09/2023  20:26    <DIR>          ..
22/07/2024  15:12    <DIR>           test folder with initial space
17/08/2018  14:10                49 format.txt
22/07/2024  15:12    <DIR>          test folder with no space
               1 File(s)             49 bytes
               4 Dir(s)  1,261,136,855,040 bytes free
7

You are right too, in a CMD line you can create such folder names with a leading space.
As soon as you try to rename it in Windows File Explorer, the leading space will be trimmed away.

8

WOuldn't this be a discussion to be held with Microsoft?
MP3tag does not create invalid folder names. And that is the way it should be I think.

9

You are right, as I already said I understand now. And I have no problem with Mp3Tag not creating invalid folder names, or with Microsoft enforcing their rules for new files/folders.

The issue which I think is certainly debatable is that the folder with „invalid” name was already created by me, and I was only instructing Mp3Tag to rename some files in it, not to create any folders. By the way, this is totally possible using Microsoft's own Windows Explorer, but not using Mp3Tag.

My opinion is that Microsoft's API should not remove spaces from EXISTING folder or file names, thus not forcing unexpected behavior on Mp3Tag and any other software using the same file system functions.

I'm saying it again: I agree that this is not a bug in Mp3Tag and this topic can be closed with an apropriate resolution. Thank you for your assistance.

10

And if you simply try to rename it trimming the space yourself Windows will tell you that it cannot do so because source and target name are the same.