# Linux: renaming/moving folders via \_DIRECTORY doesn't work

**URL:** https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358
**Category:** Support
**Created:** [May 28, 2026, 4:34pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358 "2026-05-28T16:34:02Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [May 28, 2026, 4:34pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/1 "2026-05-28T16:34:02Z")

</div>

![image](https://community.mp3tag.de/uploads/default/original/3X/f/2/f2e3c95fac8850a214aee24b6e00a954fa8b2c3d.png)  
Nothing happens when I run this action on Linux (the files remain in `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?

 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/2/c/2c25194ee68e66d70ce0dbc043ff7ef2bb392998.png)  
A similar action on Windows renames the folder to `TEST1`.

---

<div class="post-metadata">

### Author: ![Valik](https://community.mp3tag.de/user_avatar/community.mp3tag.de/valik/32/16120_2.png) [@Valik](https://community.mp3tag.de/u/Valik)
#### Post date: [May 29, 2026, 12:29am UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/2 "2026-05-29T00:29:03Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [May 29, 2026, 1:54am UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/3 "2026-05-29T01:54:10Z")

</div>

> [@Casual\_Tea](#):
>
> Is `_DIRECTORY` unsupported on Linux or is this a bug?

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?

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [May 29, 2026, 3:07pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/4 "2026-05-29T15:07:42Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [May 29, 2026, 4:05pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/5 "2026-05-29T16:05:05Z")

</div>

I can reproduce it and it looks like a missing API in Wine. I’ll see to work around that.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [May 30, 2026, 11:49am UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/6 "2026-05-30T11:49:06Z")

</div>

Yes, it was an only partially implemented `IFileOperation` which I've now worked around in [Mp3tag v3.35-beta.2](https://community.mp3tag.de/t/455).

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [May 30, 2026, 1:26pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/7 "2026-05-30T13:26:44Z")

</div>

I've tested it with 330 songs, it works as expected so far. Thank you!

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [June 12, 2026, 1:20pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/10 "2026-06-12T13:20:39Z")

</div>

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`

 ![file structure](https://community.mp3tag.de/uploads/default/original/3X/d/2/d2801b8c0342708bf3922621f3fa13b78963ed0d.png)  
This action moves the contents of `1` and `2` into the same `Test-out` folder.  
 ![image](https://community.mp3tag.de/uploads/default/original/3X/8/5/85289c9f54bbe2dcc8906cd89008e4d70435d12a.png)  
As a result, the `Cover.jpg` from folder `2` has overwritten `Cover.jpg` from folder `1`.  
 ![image](https://community.mp3tag.de/uploads/default/original/3X/f/1/f15a7e93e51301074b566eab8bae695904f0de84.png)  
I have not changed them, but here are my Messages settings just in case:  
 ![image](https://community.mp3tag.de/uploads/default/original/3X/c/c/cc43f883b0b6c918e56693224444ab6fcbfaecce.png)

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 12, 2026, 2:56pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/11 "2026-06-12T14:56:22Z")

</div>

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](https://download.mp3tag.de/mp3tag-v3.35-beta.4-x64-setup.exe)

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [June 12, 2026, 3:46pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/12 "2026-06-12T15:46:53Z")

</div>

Thank you for the quick fix!

> [@Florian](#):
>
> lets the user decide if files should be overwritten or not

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):

 ![Test result](https://community.mp3tag.de/uploads/default/original/3X/0/3/0396dfc7698971025b936bcf92a958e7f3a2d03f.png)

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.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 12, 2026, 4:14pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/13 "2026-06-12T16:14:48Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [June 12, 2026, 4:59pm UTC](https://community.mp3tag.de/t/linux-renaming-moving-folders-via-directory-doesnt-work/71358/14 "2026-06-12T16:59:20Z")

</div>

> [@Florian](#):
>
> it's reasonable to skip renaming it if the user chooses not to overwrite any of the colliding files.

Viewed like that it even makes more sense than the partial move on Windows.

> [@Florian](#):
>
> My goal is to keep Wine-specific code to a minimum, and I only added this pre-check to prevent potential data loss.

Thank you for supporting Wine usage at all and sorry if I was being unreasonable. I'll adjust my workflow.
