MP3Tag does not handle paths with a space before a folder name

[Drakonas]

Original path:
X:\Music\Collection\Video Game\Nintendo\ Exclusives\Custom Robo Battle Revolution Original Soundtrack Volume 1
After tagging/renaming:
X:\Music\Collection\Video Game\Nintendo\Exclusives\Custom Robo Battle Revolution Original Soundtrack Volume 1

It does not seem to save them in the source folder if there is a space at the beginning of a folder name. Instead it creates a new entire path that matches the original name and moves the files there, but without the preceding space.

Thank you,

[MotleyG]

This follows the Microsoft spec. See here for a similar discussion.

Whitespaces in path are wiped while renaming

Yes, i saw that post, but this happenes to my path, not filename (i checked, and my filename to tag format leaves all spaces in filename - wherever i put them). To clarify, i am not using any action for this, $left(%artist%,1)%artist%%artist% - %title% is just format in tag - filename option.

[Drakonas]

So even though this could be fixable, and the filesystem allows it, you're just going to ignore my request because it's not "kosher"?

It is in spec for the filesystem. The filesystem allows it. The issue is the function used to write the files could be changed to make it work. Directory Opus and most file managers support this. This isn't a "spec" issue, but just an oversight by whoever made the framework to write the files in my opinion.

EDIT: I meant the framework not made by MP3tag, but like whatever UI framework or if you used VisualC++'s functions, etc.

[ohrenkino]

Originally you filed a bug report.
You see that this function has already been clarified to be no bug.
MP3tag has little influence on the features of other programs.

See also this thread and please also follow the link to the Microsoft page:

Space as first caracter in path will be deleted during rename

Hi, I have updated to 3.19 64bit, coming from 2.99a. One of my mp3 folder path is "d:\mp3\verschiebene a-z\ top xxx\top100\2023.02.27". The " top xxx" has a space in front to get it on top in explorer. After renaming all files in 2023.02.27, this folder is empty, the result was created in a new path ...\top100\2023-02 without space. I thought it is deleted and have tried it again, but with the errormessage I found the bug: [Screenshot 2023-03-05 165830] It is the same in 32bit. sat24

[Drakonas]

The Microsoft link is for File Explorer, specifically. It even states on that page:

The Win32 API (CreateFile, FindFirstFile, etc.) uses a direct method to enumerate the files and folders on a local or remote file system. All files and folders are discoverable regardless of the inclusion or location of whitespace characters.

It is allowed if the correct functions are used. But I guess it's pointless for me to argue this at this point.

You say you have little influence on the features of other programs. But I should say that you can name files this way with DOS prompt. So clearly if it works in a Microsoft tool, it's intended to be possible.

[LyricsLover]

You can find some examples why you should not use leading (1) or trailing (2) spaces

in folder names here:
https://help.autodesk.com/view/CONNECT/ENU/?guid=Leading_Trailing_Spaces

Especially the trailing spaces are very tricky to visually detect and differentiate:

Even if they are technically not forbidden, I would strongly advise against the use.

[Florian]

@Drakonas

You say you have little influence on the features of other programs. But I should say that you can name files this way with DOS prompt. So clearly if it works in a Microsoft tool, it's intended to be possible.

Yes, it's possible and not sure if we can directly infer that it's intended to be possible, though. It even was supported by Mp3tag in an earlier version. Mp3tag is reading those files, so you can see that the correct functions are used.

However, there is a difference between what the file system and what the Windows Shell supports. The latter, to my knowledge, doesn't support leading whitespace characters for folder names. This is probably also the reason why those are automatically removed when creating new folders via Windows File Explorer.