What I found most interesting from working on some FUSE filesystems (and from the git pseudo-filesystem) is that removing a file via unlink is not a file operation at all, but an operation on the parent directory. The only way that the filesystem knows how to find a file (an inode) is by finding it in a directory listing (which is itself a filesystem object).

The name itself is the giveaway -- "unlink" because you're removing a hard link to a file.

Similarly, access permissions are also properties of the embedding in the directory, rather than the bits of the file itself.

This is a place where POSIX and Win32 diverge significantly -- in Win32, permissions and access happen at the file level, which is why Windows is testy about letting you delete a file that is in use, while POSIX doesn't care -- the process accessing the file, once the file is open, maintains a link to the inode, and all the file data is intact, just not findable in the directory where it was initially located.

A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the /proc filesystem.