Rubenerd

WARNING: Messing with inodes should be seen as a last resort for end users, not least seasoned sysadmins. Be extremely careful. Measure ten times, then ten more times, then cut once. I won't be held responsible for data loss, and by reading this post, you agree.

Whew. So I thought I was being all clever with my regex and batch processing foo. Unfortunately, I ended up with a stupid file named this:

$ ls
==> Ruben\ Baka

(For the pedants, this is a contrived example. The original file I had contained a smorgasboard of characters; and not in a good way).

While an accurate name, the backslash prevents renaming it with traditional tools, because the shell expands them. The road to infinity is paved with escaping escaped characters and vain attempts at wrapping quotes and such.

$ mv 'Ruben\ Baka' NewName 
==> mv: cannot stat 'Ruben\\ Stupid': No such file or directory

We can keep going down the rabbit hole of escaping characters, or we can rename the file using its inode. For those who don't know what these are, Linux Magazine ran an excellent article on them. The -i flag for ls identifies the inode for a file:

$ ls -i
==> 101010 Ruben\ Baka

Using this inode, we can rename the file thusly:

$ find . -inum 101010 Ruben\ Baka -exec mv {} NewName \;

Running this on Debian produced no output. FreeBSD and NetBSD's find commands note that they can no longer find the file under the original name:

==> find: ./Ruben\\ Baka: No such file or directory

And now we can confirm the rename was successful.

$ ls
==> NewName

Now all that's left is to tell you that inode 101010 is 42 in binary, even though inode numbers are expressed in decimal. Must you pedants ruin all the things?