UNIX for Dummies Questions & Answers

Code:

When saving, vim unlinks the original file and creates a new one.

I'm trying to understand what you are saying. I think my assertion is very simple:

Code:

$ date > date.txt
$ vi date.txt # different window, shows one line
$ date >> date.txt
$ cat date.txt
Thu Apr 18 11:46:30 PDT 2013
Thu Apr 18 11:47:57 PDT 2013

Save and exit vi

$ cat date.txt
Thu Apr 18 11:46:30 PDT 2013

Code:

When you saved the log file from within vi, 
you wiped out the changes that syslog had made.

Is this incorrect because of something about vi, or something about syslog?

Nothing to do with vi nor syslog; it's just the way the file system works.
If an editor opens a file, it reads its momentary contents, which you then can edit. During that time, another process can modify (= add to) the original file, of which the editor is not aware. When saving your edits, a NEW file is created, and the old one unlinked, which would normally mean: deleted. Compare inode numbers before and after with e.g. ls -i.
Should that other process have the old file open at that time, the link between file name and inode will be lost, but the file still exists, and can be seen by e.g. lsof. linux's debugfs has a command: undel, to recreate the link between inode and file name.

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.

On linux, if your kernel supports inotify, you can use inotifywait to watch a file. Upon notification of a process opening the file, you use lsof to see who came calling. There's a race, though. It's possible that the process may have called close() by the time lsof gets around to looking for it.

If that's unacceptable, you can almost certainly accomplish this task with selinux (something I know almost nothing about).

Regards,
Alister

Code:

$ date > date.txt
$ cat date.txt
Thu Apr 18 12:49:28 PDT 2013
$ ls -i date.txt
786451 date.txt

$ vi date.txt # different window, shows one line

$ date >> date.txt
$ cat date.txt
Thu Apr 18 12:49:28 PDT 2013
Thu Apr 18 12:50:31 PDT 2013

Save and exit vi

$ cat date.txt
Thu Apr 18 12:49:28 PDT 2013
$ ls -i date.txt
786451 date.txt

The inode did not change. Whenever I read one thing in a man page, and see another thing in practice, I tend to believe what I see. But I'm willing to be educated.

Don,

Thank you very much for elaborating on vim's behavior and thanks also for the POSIX update information.

Regards,
Alister

---------- Post updated at 04:03 PM ---------- Previous update was at 04:01 PM ----------

There are many vi implementations. Yours may not have changed the inode, but at least one very popular implementation will under certain circumstances (as detailed in Don Cragun's post).

Regards,
Alister

I would say it's as clear as mud at this point. I examined the inode. It did not change. It doesn't help much to cite long-winded official explanations. I am willing to believe the inode could change when vi writes out the file. Can someone provide an example of that happening?

The previous post from RudiC said "Nothing to do with vi nor syslog; it's just the way the file system works." Nobody contradicted that. My example seems to contradict the assertion.

FWIW, I'm using vim on linux.