<< back
Problem:
I recently ran into an issue wherein when file had been created, the creator of said file had managed to include some special characters in the filename from a copy/paste operation into the name in vs code. Non-rendered special characters, no less, so any operation against the file resulted in a failure to find it, in spite of what you'd see when you looked in the directory. VS code would display it (sans special characters), but couldn't find it to open or remove. A terminal would also show the file, but would experience the same issue!
So, let's get to our example.
After creation, the file looked like this:
somefile_1.xml
Fortunately, this file was in a git repo, and git is relentlessly literal, so when you went to check status, you'd see this:
jdm@devforce03:~/projects/someproject$ git status
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
"\357\273\277somefile_1.xml"
no changes added to commit (use "git add" and/or "git commit -a")
Any attempts to mv or rm met with failure, in the following flavors:
rm somefile_1.xmlrm "somefile_1.xml"rm "\357\273\277somefile_1.xml"
All of these returned 'file not found' errors. So, what's next, then?
Solution:
Fortunately, the most common linux filesystem types offer a way around this; namely, referencing a file by inode value vs string name. So, in my case, we start out getting inode value for the file:
jdm@devforce03:~projects/someproject$ ls -li
...
55875719 -rw-rw-r-- 1 jdm jdm 662 Jan 4 09:50 somefile_1.xml
...
We could then use the inode value in conjunction with the find command with the -exec flag, like so:
find . -inum 55875719 -exec mv '{}' './killme' ';'
Note: this could have been an rm as well, but I wanted to make sure it identified the correct file beforehand in a marginally non-destructive fashion:
jdm@devforce03:~/projects/someproject$ ls -l
...
-rw-rw-r-- 1 jdm jdm 662 Jan 4 09:50 killme
...
After that, it was as easy as rm ./killme, and we were back in a clean state!
I hope this saves some of you some trouble in the future. Happy scripting!
