Bug 40470 - vim saves to new inode, stomps on filehandles
vim saves to new inode, stomps on filehandles
Product: Red Hat Linux
Classification: Retired
Component: vim (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-05-14 01:56 EDT by ratness
Modified: 2007-04-18 12:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-30 11:27:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ratness 2001-05-14 01:56:27 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.
Comment 1 Bernhard Rosenkraenzer 2001-05-14 07:03:45 EDT
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 
Comment 2 Ben LaHaise 2001-05-18 15:11:54 EDT
What is the nfs server in this case?  Invalid filehandles are typically a server
Comment 3 ratness 2001-05-18 19:37:29 EDT
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.
Comment 4 Bernhard Rosenkraenzer 2001-07-03 16:01:02 EDT
Doesn't happen in the version from rawhide
Comment 5 ratness 2002-05-31 07:41:02 EDT
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.
Comment 6 Kevin Sonney 2002-11-30 11:27:27 EST
This appears to still be the case in 8.0 as well.
Comment 7 Karsten Hopp 2002-12-03 06:19:54 EST
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.
Comment 8 ratness 2002-12-03 10:05:21 EST
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.

Note You need to log in before you can comment on or make changes to this bug.