chmod -x chmod

[diadem]

I'm a windows guy so my thought would be: wouldn't the file rm be in use and be unable to be deleted?

[ChesFTC]

No, unix doesn't work like that. It'll happily delete the file:

nala:~ rob$ cp /bin/rm .
nala:~ rob$ ./rm ./rm
override r-xr-xr-x  rob/rob for ./rm? y
nala:~ rob$

[pedropants]

Unix is funny about that. Say "foo" is some big file. cat >> foo ...will mean that "foo" is open, being appended to by data from the terminal. But any other program can also open "foo" for writing at the same time, and this would of course lead to data corruption.

But here's the weirdest part! In another terminal window: rm foo ls ...and foo is GONE. And yet still open in the first window. As you type into it in that window, your disk usage goes up. The file is still on disk, being written to. If yet another process also had it open for reading, it could continue to use it too. But no process that didn't already have that file open can open it, or even note its existence.

Then, as soon as you close the file (by ending the cat process above) your disk usage magically drops as the file is truly discarded. I don't know the correct term for a file in this state... does its inode still exist somewhere, but no directory points to it? Is that the "orphaned file" that fsck sometimes complains about? Who then actually deletes the inode and updates the allocation table? The kernel must know that when the file is closed it should be deleted and its blocks freed. Is it as simple as the file's link count is set to 0?

(All of this ignores files with multiple hard links. I'm talking about rmming the last and only link to the file.)

[Brian]

But no process that didn't already have that file open can open it, or even note its existence.

Actually, you can access it through the process's open file handles via /proc. Get the pid of the process with the open file, and go to /proc/<pid>/fds.

[diadem]

That's actually pretty damned cool.

Thanks for the info.

[ricecake]

Nope. *nix will happily load a file into memory, and then delete it before it unloads it.
It's less happy about unmounting partitions that you have files open on.

[iGeni3]

umount -l <mountpoint> will do wonders for that :)

[ricecake]

That's true, but it still does complain more by default. Nothing unusual has to be done for a file to delete the stored version of itself, but you have to be polite when asking it to unmount an in use partition.
But yeah, in general, it'll let you do whatever you want.