linux - Why file is accessible after deleting in unix?

Question

I thought about a concurrency issue (in Solaris), what happen if while reading someone tries to delete the same file. I have a query regarding file existence in the Solaris/Linux. suppose I have a file test.txt, I have open it in vi editor, and then I have open a duplicate session and remove that file, but even after deleting that file I am able to read that file. so here are my questions:

• Do I need to thinks about any locking mechanism while reading, so no one able to delete same file while reading.

• What is the reason of showing different behavior from windows(like in windows if file is open in in some editor than we can not delete that file)

• After removing that file, how I am still able to read that file, if I haven't closed file from vi editor.

I am asking files in general,but yes platform specific i.e. unix. what will happen if I am using a java program (buffer reader) for read file and file is deleted while reading, does buffer reader still able to read the file for next chunk or not?

Answer 1

You have basically 2 or 3 unrelated questions there. Text editors like to read the whole file into memory at the start of the editing session. Imagine every character you type being saved to disk immediately, with all characters after it in the file being rewritten one place further along to make room. That would be awful. Much better that the thing you're actually editing is a memory representation of the file (array of pointers to lines, probably with some metadata attached) which only gets converted back into a linear stream when you explicitly save.

Any relatively recent version of vim will notify you if the file you are editing is deleted from its original location with the message

E211: File "filename" no longer available

This warning is not just for unix. gvim on Windows will give it to you if you delete the file being edited. It serves as a reminder that you need to save the version you're working on before you exit, if you don't want the file to be gone.

(Note: the warning doesn't appear instantly - vim only checks for the original file's existence when you bring it back into the foreground after having switched away from it.)

So that's question 1, the behavior of text editors - there's no reason for them to keep the file open for the whole session because they aren't actually using it except at startup and during a save operation.

Question 2, why do some Windows editors keep the file open and locked - I don't know, Windows people are nuts.

Question 3, the one that's actually about unix, why do open files stay accessible after they're deleted - this is the most interesting one. The answer, guaranteed to shock you when presented directly:

There is no command, function, syscall, or any other method which actually requests deletion of a file.

Underlying rm and any other command that may appear to delete a file there is the system call unlink. And it's called unlink, not remove or deletefile or anything similar, because it doesn't remove a file. It removes a link (a.k.a. directory entry) which is an association between a file and a name in a directory. (Note: ANSI C added remove as a more generic function to appease non-unix people who had no intention of implementing unix filesystem semantics, but on unix, remove is just a rmdir if the target is a directory, and unlink for everything else.)

A file can have multiple links (see the ln command for how they are created), which means that the same file is known by multiple names. If you rm one of them, the others stick around and the file is not deleted. What happens when you remove the last link? Well, now you have a file with no name. But names are only one kind of reference to a file. There are at least 2 others: file descriptors and mmap regions. When the last reference to a file goes away, that's when the file is deleted.

Since references come in several forms, there are many kinds of events that can cause a file to be deleted. Here are some examples:

• unlink (rm, etc.)
• close file descriptor
  • dup2 (can implicitly closes a file descriptor before replacing it with a copy of a different file descriptor)
  • exec (can cause file descriptors to be closed via close-on-exec flag)
• munmap (unmap memory region)
  • mmap (if you create a new memory map at an address that's already mapped, the old mapping is unmapped)
• process death (which closes all file descriptors and unmaps all memory mappings of the process)
  • normal exit
  • fatal signal generated by the kernel (^C, segfault)
  • fatal signal sent from another process (kill)

I won't call that a complete list. And I don't encourage anyone to try to build a complete list. Just know that rm is "remove name", not "remove file", and files go away as soon as they're not in use.

If you want to destroy the contents of a file immediately, truncate it. All processes already using it will find that its size has suddenly become 0. (This is destruction as far as the normal file access methods are concerned. To destroy it more thoroughly so that even someone with raw disk access can't read what used to be there, you need to overwrite it. There's a tool called shred for that.)