TEST).
However when I use _FILENAME instead of _DIRECTORY, Mp3tag has no problem moving the audio files to new folders (leaving behind lyrics, covers, log files etc.).
Is _DIRECTORY unsupported on Linux or is this a bug?
TEST1.
I’m testing MP3tag on Linux via Wine and have also found that changing %_DIRECTORY% is the part that doesn't work. Tag changes work, and filename-based changes can work, but actions intended to rename the containing folder via %_DIRECTORY% don't.
The formatting/preview side can look correct, but when I apply the action using %_DIRECTORY%, the existing album folder remains unchanged. On Windows, the same general approach is part of my normal workflow.
The important distinction for me is that I’m not trying to move only the audio files into a newly named folder. I want MP3tag to rename the existing album folder so that artwork, logs, etc. are all kept together. Using %_FILENAME% can move the audio files, but that is not really a replacement for renaming the parent directory.
So from my side this looks like either %_DIRECTORY% is not fully supported in the Linux/Wine setup, there is a bug/limitation specifically around renaming/moving folders rather than files, or Wine’s handling of Linux-mounted paths/drive mappings is getting in the way somehow.
Not a Linux user here so this may not be correct. But doesn't the directory protocol there use forward slashes / to separate the structure levels?
Wine translates the file paths so Windows programs can access the host's file system. Per default, the root partition on Linux: / is mounted as Z:\.
This allows Mp3tag to access /home/malte/Music on the host as Z:\home\malte\Music in Wine without issues.
I can reproduce it and it looks like a missing API in Wine. I’ll see to work around that.
Yes, it was an only partially implemented IFileOperation which I've now worked around in Mp3tag v3.35-beta.2.
I've tested it with 330 songs, it works as expected so far. Thank you!
This change seems to have had a side effect.
If 2 source folders get merged into one target folder and a file with the same name was present in both source folders, the first source file is overwritten by the second source file with no prompt, potentially leading to data loss when their content was not identical.
Reproduction steps:
2 songs in a subfolder each beside different cover files both named Cover.jpg
1 and 2 into the same Test-out folder.
Cover.jpg from folder 2 has overwritten Cover.jpg from folder 1.Thanks for reporting!
It's looks like Wine's implementation of IFileOperation also skips collision detection and all the niceties the Windows version brings with it.
I've now implemented a simple pre-check that's only effective when running under Wine that lets the user decide if files should be overwritten or not.
It would be great if you could try the new beta:
https://download.mp3tag.de/mp3tag-v3.35-beta.4-x64-setup.exe
Thank you for the quick fix!
From the results I'm seeing, the user's choice affects all files in the specific source folder and not only the file(s) with colliding names like on Windows where only the Cover.jpg files would be left behind.
Saying "no" to overwriting repeatedly (I've added 2 more subfolders to my test):
This might lead to odd behavior for existing action groups that assume that all audio files have been moved by a previous action but it's better than silently overwriting files.
Yes, because the action is about renaming the directory, I think it's reasonable to skip renaming it if the user chooses not to overwrite any of the colliding files.
The alternative would be to create a completely separate implementation from the one I'm currently maintaining for the Windows version. My goal is to keep Wine-specific code to a minimum, and I only added this pre-check to prevent potential data loss.
Viewed like that it even makes more sense than the partial move on Windows.
Thank you for supporting Wine usage at all and sorry if I was being unreasonable. I'll adjust my workflow.
