# \[X\] Renaming with '\\' file directory bug
**URL:** https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809
**Category:** No Bugs
**Created:** [June 14, 2014, 5:58pm UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809 "2014-06-14T17:58:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Porygon](https://community.mp3tag.de/u/Porygon)
#### Post date: [June 14, 2014, 5:58pm UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/1 "2014-06-14T17:58:36Z")
If a song has a \ symbol in its name (as opposed to /), automatically renamng the song causes it to get placed into a file directory because \ creates a directory.
For example:
Song name -\> Short skirt \ Long Jacket
This was track number 4
I used Alt + F1 to rename it to 04 Short Skirt \ Long Jacket
However, this action named it Long Jacket and placed it into a Folder named 04 Short Skirt
Is there a way to blacklist the \ symbol, as this creates directories?
NOTE: I changed the song to Short Skirt / Long Jacket to avoid this problem
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 14, 2014, 6:27pm UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/2 "2014-06-14T18:27:26Z")
Where is the bug?
You used an illegal character for a filename as the backslash is part of a path.
The backslash may be inserted deliberately if you want to move a file to a different folder. That is why it is not blackslisted by default.
If you are not sure whether the automatic renaming will lead to valid filenames then enclose the whole filename mask into a $validate() statement. (see help for more details).
---
### Author:  [@ExiledLife](https://community.mp3tag.de/u/ExiledLife)
#### Post date: [November 2, 2014, 1:43am UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/3 "2014-11-02T01:43:15Z")
I have been having this issue as well. I feel that MP3 Tagger should just ignore "" entirely. I see no reason to have it since it does not work.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [November 2, 2014, 6:45am UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/4 "2014-11-02T06:45:29Z")
> [@ExiledLife](#):
>
> ... since it does not work.
I think I described the function of the backslash.
So could you please specify in what respect it does not work?
There is one function ("create a subdirectory") and that does work.
On the other hand: there is no safeguard from misuse. Even though you might not have expected the result, other users might just as well have intended it.
---
### Author:  [@vkostas](https://community.mp3tag.de/u/vkostas)
#### Post date: [November 2, 2014, 3:43pm UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/5 "2014-11-02T15:43:11Z")
> [@ExiledLife](#):
>
> I have been having this issue as well. I feel that MP3 Tagger should just ignore "" entirely. I see no reason to have it since it does not work.
I see you point but I wouldn't consider this as a bug. It is rather a feature.
If you want to be really "safe" when renaming filename you should foresee those 8 characters ( **/:_?\<\>|_** _).
You should define an encoded format for each of those characters.
E.g. **\<** = **\<** , **\>** = **\>** , **/** = **&slash;** , **\ = &bslash;, : = :,** _ **= &asterisk;, ? = &qmark;.
Therefore two replace commands 1. Tag -\> Filename**
**```
$replace(string, "<", "<", ">", ">", "/", "&slash;", "\", "&bslash;", ":", ":", "*", "&asterisk;", "?", "&qmark;")
2. Filename -> Tag
$replace(string, "<", "<", ">", ">", "&slash;", "/", "&bslash;", "\", ":", ":", "&asterisk;", "*", "&qmark;", "?") could be used for filenames.**
**```**
Use your "own" encoded string for each of 8 characters.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:34pm UTC](https://community.mp3tag.de/t/x-renaming-with-file-directory-bug/15809/6 "2018-12-28T14:34:10Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.