UNIX for Dummies Questions & Answers

I have to admit that Hanson44 is right - some editors reuse inodes (which, BTW, was not the topic of this thread).
I'm using joe; its reusing inodes as well, which I never noticed before. But, this guy is smart: if you edit a file, and another process adds/edits as well, it tells you before allowing to edit:

Code:

Notice: File on disk changed! (hit ^C to continue)

and, when trying to finally write the file, it issues:

Code:

File on disk is newer. Overwrite (y,n,^C)?

Code:

$ echo foo > file
$ cat file
foo
$ ls -i file
472445 file
$ # vim 7.0 opens file in a different terminal, showing just one line, "foo"
$ echo bar >> file
$ cat file
foo
bar
$ ls -i file
472445 file
$ # vim :wq in the other  (after it warns that the file has changed)
$ cat file
foo
$ ls -i file
472449 file

A syscall trace of vim 7.0 reveals the source of the new file with the new inode number:

Code:

rename("file", "file~") = 0
open("file", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 3
write(3, "foo\n", 4)
...
close(3)
...
unlink("file~") = 0

Before writing, this version of vim is using the rename system call to move the original file to file~. It then uses the open syscall with the O_CREAT flag to create a different file. It then writes the contents of the buffer to this new file before unlinking the backup copy (which is the original file and points to the original inode).

Your example does not contradict anything. It merely demonstrates that a different sequence of calls is being made.

Regards,
Alister

Thank you for verifying with a different editor. It was obvious from the tests I did that the same file was being written to, regardless of what some man page or specification might suggest.

Just to make sure, I did the same test on syslog. If you edit syslog (normally not a good idea), wait a while for something to be appended, write and exit vi, the newly added content is not there. The original poster thought syslog stopped working only because the newly added content was overwritten with the original file when vi saved/exited.

This could be insidious, actually. If the old file is deleted and a new one created, syslog will apparently stop working, since the old, deleted file will remain on disk -- and keep getting written to -- until syslog rotates the file itself for some reason or the machine restarts.

What puzzles me is why anything under /var/log was being edited at all.

In my posts, including the last one, I have repeatedly said it is NOT a good idea to edit syslog (or other system log file). So I am in 100% agreement. I just did this as a one-time operation (a great sacrifice ) to test the assertion that syslog would continue to be written due (and the content preserved), even if vi edited and saved the file. There was no other way to test it.

If by "overwritten" you mean that the editor changed the file's contents, then you are wrong. If by "overwritten" you mean that the editor created a completely different file, then you are correct.

If an editor simply overwrites the file's contents, after the edit, syslog's new messages would continue to appear in the file.

If the messages cease to reach the named file, then the original file has been unlinked and replaced by a new file (a different inode) with the same name. Meanwhile, syslog is still happily logging to the original log file (now with no name).

The OP stated having to restart to resume logging. That would not be necessary if the file's inode had not changed.

Regards,
Alister

I can't seen the OP's machine to know what really happened. If restart was really needed, then I agree. On my test, restart was not needed. Anyway, based on our tests (see below), it all makes sense.

----------------------------

Code:

Your test:
$ echo foo > file
$ cat file
foo
$ ls -i file
472445 file
$ # vim 7.0 opens file in a different terminal, showing just one line, "foo"
$ echo bar >> file
$ cat file
foo
bar
$ ls -i file
472445 file
$ # vim :wq in the other  (after it warns that the file has changed)
$ cat file
foo
$ ls -i file
472449 file

I just saw this previous post (above). It was at the same time I posted, so got missed. I re-ran the exact sequence of operations (below), using vim 7.3.547 and linux, as a reality check, and the inode does not change:

Code:

My re-test:
$ echo foo > file
$ cat file
foo
$ ls -i file
786454 file
$ # vim 7.3 opens file in a different terminal, showing just one line, "foo"
$ cat file
foo
$ echo bar >> file
$ cat file
foo
bar
$ ls -i file
786454 file
$ # vim :wq in the other  (after it warns that the file has changed)
$ cat file
foo
$ ls -i file
786454 file

It seems you have shown that vim can be configured to create a new file with a new inode. As you explained, it has something to do with the backup file. My vim happens not to be configured that way (I don't think I would want it configured that way). The OP could well have had their vi configured in that way, so that would explain what happened. But that wasn't the question. The previous contention was that vim had to create a new file, that the inode had to change, due to something more fundamental going on. It was the believable idea Nothing to do with vi nor syslog; it's just the way the file system works that nobody else objected to, that I decided to investigate. I just wanted to know the answer. My test shows that shows vim does not have to create a new file. Your test shows vim can be configured to create a new file.

If the inode does not change, isn't it still the original file? The inode does not change in my test, as shown above. Your test shows that vim can be configured to create a new file under the test conditions, not that the new file creation is inevitable or required. I appreciate that you posted the test, and helped clarify this.