4 ms·
When removing files in odd situations on unix systems, I'm a big fan of: 01:30 shephard:shephard shephard$ touch foo 01:30 shephard:shephard shephard$ ls
by ghshephard 11y ago
When removing files in odd situations on unix systems, I'm a big fan of:
01:30 shephard:shephard shephard$ touch foo
01:30 shephard:shephard shephard$ ls -li
total 0
102600870 -rw-r--r-- 1 shephard 2000 0 Nov 20 01:30 foo
01:30 shephard:shephard shephard$ find . -inum 102600870 -exec rm {} \;
01:30 shephard:shephard shephard$ ls -li
But - it doesn't work in this situation of long symlink. Wild.
shephard:~ root# ls -li $str1/$str2/$str3/$str4
total 8
102601971 lrwxr-xr-x 1 root wheel 3 Nov 20 01:37 L -> ftw
shephard:~ root# find $str1/$str2/$str3/$str4 -inum 102601971 -exec rm {} \;
rm: 1.../2.../3.../4..../L: No space left on device
shephard:~ root#
- eridius 11y agoWhy would that behave any differently than just calling rm directly? find isn't somehow invoking rm with the inode, it's just passing the path to rm.
- the_mitsuhiko 11y agoIt would not. The way to unlink files is by path and not by inode. I don't think you can actually delete by inode on OSX.
- JupiterMoon 11y agoJust guessing but maybe the shell is eating the filename rather than rm eating it?
- eridius 11y agoThe article demonstrated trying to make the syscall directly and still receiving the error, which rules out any shell shenanigans.
- JupiterMoon 11y agoMy bad. I should rta.
- ghshephard 11y agoThis is useful when the file name gives the shell coniptions, such as when you are trying to remove a file named * or \ or $ or - . Anytime I see a file like that, I don't even try and figure out how to convince the shell/rm to properly escape the characters, I just switch back to the inode approach. But yes, doesn't help for filenames that are too long.
- heinrich5991 11y agoThis could go horribly wrong when the filename contains newlines, right? Like `foobar\n/etc/passwd`.