Renaming folder not showing up in mp3tag

I go into windows explorer and rename a folder. I then start mp3tag on that folder (either from the context menu or loading within the program and it still shows the old name. There's nothing particularly unusual about the folder name and I've renamed other folders in that same parent folder and thet get updated

Are you sure that you use the correct folder?
Anyway: if you say yourself

then you would have to present a lot more details on what happens - I mean it is rather unsual in the IT environment that something should work most of the times and then all of a sudden it does not.
Preferably screendumps of the whole process would help as no one can look over your shoulder from the distance.

Apparently this is a known behavior of Windows 10. Apparently folder names are not necessarily the same as directory names. I think if the directory is marked Read-Only then folder renames are stored in desktop.ini instead of changing the underlying directory name.

And mp3tag shows the directory name rather than the folder name. I would guess Microsoft wants software to use the folder name, but I haven't looked into that

Interesting. Could you give me a link where to find descriptions so that this behaviour becomes also known to at least me?
I just tried to make a folder "read-only" - which I couldn't as WIndows says that this only applies to the files in it.
The found file desktop.ini has no reference to a directory name - or at least I can't see it:


This sounds to me like a misunderstanding of the behaviour that Windows has with localized folders and desktop.ini-files. (getting off-topic now)
I had to make a research sometimes ago because I noticed that my localized Users-folder ("Benutzer" in german) suddenly had lost its localization and was called "Users" in windows-explorer. I had to repair the desktop.ini-file and make the folder read-only to correct this behaviour.

You have to open a console-windows with administrative rights, in my case mentioned above:
attrib c:\users +R

The reference to the localized directory name is on the line
The localized name stands in the file shell32.dll

However, all this has nothing to do with the described problem of the thread opener, unless the renamed folder is possibly a Windows system folder.

I quite agree.
The OP claims

so I would assume that this is just a plain data folder.
A possible problem could arise if the workflow is not quite what the OP describes:

but instead MP3tag loads the folder first and then the folder gets renamed in WE. Then it would necessary to press F5 or load the folder again.

Well, to my definition the folders "Music, Videos, Pictures ..." are windows-system-folders, also they are data-folders.
And in my experience, it's a popular behavior for users to mess around with these kinds of things which can have a lot of unwanted side-effects..

If you rename your Music-folder to "MP3-Music", Windows writes this line to the desktop.ini-file:
and shows this localised name in the explorer if the folder "Music" is still read-only.
If you disable read-only the localized name changes to the original name.

In order to achieve the effect independently of the specified system folders, you have to create a desktop.ini file yourself with the appropriate section [.ShellClassInfo]. After that, Windows only writes every renaming of the folder in the desktop.ini and keeps the original name. So it needs some "destructive effort" to achieve this.
But regardless of this, scenarios are of course also conceivable in which desktop.ini files with this section are copied from one folder to another without being noticed.

Incidentally, MP3Tag generally ignores localized folder names and always shows the actual folder name of the file system.

Are you sure?
I can see the non localized "Pictures" folder name in the title bar of Mp3tag.
I can see the non localized "Pictures" folder name in the variable %_folderpath%
If I try to open a folder inside Mp3tag, I see the localized "Bilder" folder name on several places.

Where exactly do you see Mp3tag ignoring localized folder names elsewhere?

I think we are still talking about the special folders that WIndows creates on setup.
The location is usually c:\music for music files.
The displayed name in the WE ist then localized.
You can move the location anwhere you want (e.g. because C: becomes congested somehow) with the properties dialogue of such a special folder and the tab "Path". You have to use this function. It is not possible to simply rename such a folder in the folder tree or the object list.

All this meanders around the special folders. I wonder what the OP will tell us, which folder got renamed and what the path looked like.

I think this is because MP3Tag uses the explorer then?

  • In the tag-panel (Directory).

  • In the variables:

  • In the preview of the converter.

If you use absolute paths with actions or the converter to rename folders, MP3tag will create additional folders with the localized names.

1 Like

This more precisely describes the issue: command line - Windows explorer sees different file name from cmd - Super User

My folder was under my profile directory, but not in one of the Windows System folders

I can tell from my report that mp3Tag displays the directory name rather than the folder name. It's not clear to me that this behavior is ideal.

Then it should not display a localized folder name itself, unless a desktop.ini file with a localized name has been created in this folder and the Read-only setting has been set for the folder. A folder you have created yourself does not initially contain such a disktop.ini file, least of all with localization content and is not set to read-only. You have to consciously change something like that yourself.

If, in your case, you mean the display of the path in MP3Tag to the folder you have created, your observation would be correct. In the Windows basic setting, localized folder names are located in the path of your profile folder. As far as I know, displayng not localized names is always the case when the software does not use Windows Explorer, which only happens when navigating in the Explorer tree and selecting folders and files.
Even Windows itself does not show any localized names in its console or in its system and user variables.

1 Like

If you want to see the same folder- and directory names everywhere, you can apply the solution in the above linked Super User answer:

Whenever a directory is marked with the read-only attribute, Explorer displays it according to what's specified in the desktop.ini file in that directory.

and the final solution:

Delete, rename or edit the desktop.ini files in these directories.

On my german Windows 10 the localized folder "Bilder" would be called "Pictures" everywhere, as soon as I delete the desktop.ini inside my %userprofile%\pictures folder:

Don't forget:
You have to restart every running "Windows-Explorer" process before you can see the changes.

Just as a supplementary note:
One should not "demonize" the desktop.ini file as it happens in many advisory sections in many places on the net.

In addition to the entry in the section [.ShellClassInfo], which is responsible for the localized name of a folder, the desktop.ini file also serves the appearance of a folder in Windows Explorer.
In this regard, Windows Explorer offers its own "destop.ini-Maker" in Properties-> Customize.
In any case, I personally find an adaptation of the destop.ini file in my top-level music folder and the inheritance to the sub-folders for the "Music" display very useful. This saves me from having to individually set for each folder that columns are displayed in the displayed content for the common tags such as "album, artist, album artist, track number ...".


I'm not convinced that mp3tag using the directory name is the best behavior

The folders are generally created by the software that downloads the music. I've recently started using a new piece of software which I think uses the localized name to get around the maximum path length limitation.

Since mp3tag doesn't allow renaming the containing folder (hint, hint), I can't see opening a console window when I want to rename a folder so I would guess most of us use Windows Explorer to rename folders. Hence it seems desirable that mp3tag reflect what we see in Windows Explorer

You can easily check this yourself by checking whether there is a (hidden) desktop.ini file in the folder created by the software and whether it contains the following:
LocalizedResourceName = .(referring to a filel or naming a localized folder)

Coming back to the original post, in the meantime it looks to me like this description was not really accurate. We have learnt


So it is a local setup with programs that use Windows functions in a suprising way
If I had such a system where I could not rely on the data that is displayed, I would get to root of things and then take measures to get it in line again.
In the discussed case it looks to me as though the culprit is a desktop.ini file that hides the real data from me. So for me the consequence would be to either delete the file entirely if it serves no real purpose or remove at least the incriminating entries that hinder changes from becoming obvious.
I mean: what happens if I delete the file desktop.ini? All of a sudden I don't find my folders any more as they revert to the old names.

I have moved my "Documents" folder to a different drive and folder, let's say "d:\my_papers".
The folder called "Documents" und "My computer" shows the local name "Documents".
When I click on that entry, I see a folder with "Documents" in the folder tree but the Explorer window title shows "d:\my_papers", the address box shows the same data as the tree as long as it does not get the focus. As soon as I click into address box, the real path "d:\my_papers" is shown.
So perhaps our OP could check what his explorer really knows about the names.

In fact, I renamed almost 100 folders so figuring out which might have been affected is not trivial.

Also, as this is new with Windows 10, my impression is that this behavior will become more more common over time. That's why I think mp3tag should consider adopting it. I understand it's not a trivial decision since there are almost certainly mp3tag users who also use command-line utilities. Having the behavior be user-selectale might be a compromise

If you mean the type of localization of folders via the desktop.ini file - as far as I can remember it was introduced with Windows Vista 2006, 15 years ago.