The description of how unlink() works on a file is correct. The statement that vim unlink()s the file is an optimization used by vim under certain circumstances. It isn't clear to me that the standards allow this optimization in the case being discussed in this thread. The standard clearly does not allow this behavior when there are multiple links to the file being edited and vim doesn't unlink() (or more likely rename(tmp_file, original_file)) the original file when there are multiple links.

To verify this, execute the following commands:

Code:

$ touch x1 x2
$ ln x2 x3
$ ls -li x[1-3]

You will note at this point that there are two links to x2 and x3 and that they have the same i-node number (in POSIX referred to as the file serial number).
If you then edit x1 with vim to add some text and save the file before exiting vim and rerun the ls, you will indeed see that the i-node number of x1 has changed.

However, if you edit x2 with vim, add some text, save the file before exiting vim, and rerun the ls; you will see that x2 and x3 both still have the same (unchanged) i-node number but the added text is now in this file and visible not matter which link is used to access the file. So, vim only performs this optimization when there is only one link to the file. In my personal opinion, that fact that vim ever does this is a bug.

The standards have a detailed description of how file handles have to be shared between and within processes to get the desired results; and when two processes are updating a file at the same time (as is being described in this thread) the results are undefined. For those of you with access to the 2008 Issue of the POSIX Standards (or the 2013 edition including technical corrigendum #1 to be released tomorrow) this text appears in the System Interfaces volume of the standard in subclause 2.5.1 titled Interaction of File Descriptors and Standard I/O Streams.