Whitespaces in path are wiped while renaming

Hello,
I would like to report this problem:
I use tag to filename option to organize mp3 files into folders, like this:

tag-filename
$left(%artist%,1)%artist%%artist% - %title%

This should do this with path:

from:
h:*****Sort Music\pending\2 Unlimited - Get Ready For This.mp3 (notice few whitespaces in path, *)

to this:
h:*****Sort Music\pending\2\2 Unlimited\2 Unlimited - Get Ready For This.mp3

But, since the new 3.09 version, whitespaces get deleted from path, and thus all files get moved to new path (without spaces), and it gets a bit annoying.

This is what happens:
h:\Sort Music\pending\2\2 Unlimited\2 Unlimited - Get Ready For This.mp3

In the last 3.08, this didn't happen.
How can this be fixed?

Sorry if this was discussed elsewere, but I didn't find it.

see here:

and the list of fixed bugs:
https://community.mp3tag.de/t/mp3tag-v3-09-released/54399/2

1 Like

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.

AS far as I understand the discussion and the Microsoft Specification "File and Folder names that begin or end with the ASCII Space (0x20) will be saved without these characters." means that a folder name with leading or trailing space characters is invalid.

The presence of spaces in a filename is not relevant for the data transfer to tag fields.

If you rename a file, then the filename is only the partially qualified name. The fully qualified name has the full path.
So following the logic of the Microsoft specification any folder name with leading or trailing spaces is invalid and MP3tag attempts to write only valid names.

This i'm complaining about happens now in 3.09, and didn't happen in 3.08.

This is how i work, i add few spaces in folder name to keep it at the top. I know WinExplorer doesn't allow those spaces, but i work in TotalCmd.
WinExplorer tolerates spaces in path, but deletes them on rename or copy.

If Mp3Tag changed way it manipulates files from the last 3.08 version, that may be our answer...

So you know that you use invalid filenames.
I

I don't know if you read the section about fixed bugs:
"renaming files with creating folders could possibly result in invalid folders names ending with spaces or dots. "
So, yes, that got changed as it was considered a bug.

Alternatively to the leading space characters, IMHO it would be an option to use leading underscores. These woud be valid characters and lead to valid filenames and folder names.

1 Like

Like I said, i know WinExplorer doesn't like spaces in path, but windows tolerates them. It is my way of working for a long time, and never had any issues anywhere except for some old cmdline programs.
It still isn't a problem, but annoyance, i wanted to point out that Mp3Tag's behavior has changed in this matter.

I know about this as well. but i'm not used to it. Anyway it's easier to slap space a few times than to make underscores (it is also easier to read).

Anyway, if author of the program reads this, I would like to ask to allow path AS IS (old behavior).

For the longest time this used to be also my modus operandi - but I had to give it up as some pieces of software did not complied with Microsoft's approach in this matter while others did do [and so it was creating chaos among my files and folders]

You can read another discussion about this issues here:

https://freecommander.com/forum/viewtopic.php?f=19&t=8567

For the time being I simply started adding ! sign before all those white space - this way even if some software decides without my consent to remove them, I still will be able to spot them, as they will be at the top because of that leading mark in form of ! sign

1 Like

My go-to for making items sort to the top of lists is the underscore character. Legal everywhere, and works everywhere (that I've tried).

1 Like

Moved to #bug-reports:no-bugs

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