Red Hat Bugzilla – Bug 40470
vim saves to new inode, stomps on filehandles
Last modified: 2007-04-18 12:33:12 EDT
Description of Problem: The vim package in 7.1 saves files in a manner that the file resides in a new inode. If a process has an open filehandle on that file, the filehandle will become stale. How Reproducible: Every time using vi; none of the time using pico, or 'echo "blah" > /var/log/messages' Steps to Reproduce: 7.1 box, base install. 1. stat /var/log/messages, and lsof|grep syslog|grep messages; note the inode number and the valid filehandle 2. vi /var/log/messages, delete a few lines, :wq 3. re-stat, re-lsof Actual Results: lsof shows the filehandle is closed, stat shows that the inode is changed, and syslogd can no longer output to that file Expected Results: syslog should have a valid filehandle after using vi on a file it has already opened. Additional Information: vi as shipped in 7.0 does not exhibit this problem. I know the problem may not be RH's and that the 7.1 vi is alpha code, but you should at least be aware of the problem, since it's possible for this problem to bite people.
The new file writing code is supposed to be a feature (eliminates some security problems from 5.7). I'll check if we can get rid of the adverse effects.
What is the nfs server in this case? Invalid filehandles are typically a server problem.
Hope this question was aimed at me. There is no NFS server. The problem was noticed on /var/log/messages, upon which syslog usually has an open filehandle. /var is boring stock internal IDE disk (/dev/hda5 on /var type ext2 (rw)). After munging /var/log/messages in `vim`, `lsof` indicated the filehandle was closed, and `stat` showed a new inode number.
Doesn't happen in the version from rawhide
This bug reappeared when you made vim6.0 part of the 7.2 errata, and it's in vim6.1 in the 7.3 release.
This appears to still be the case in 8.0 as well.
As Bero already mentioned, this isn't a bug but the intended behaviour to fix a security problem. You have to send a SIGHUP to syslogd when you edit /var/log/messages or one of the other logfiles.
Then, is it a security problem that pico and "echo foo >> /var/log/messages" don't change inodes? This /is/ a bug, in that a simple editing of a text file produces dissimilar and unexpected results across editors.