Bug 40470 - vim saves to new inode, stomps on filehandles
Summary: vim saves to new inode, stomps on filehandles
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vim
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-14 05:56 UTC by ratness
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2002-11-30 16:27:33 UTC

Attachments (Terms of Use)

Description ratness 2001-05-14 05:56:27 UTC
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 11:03:45 UTC
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 19:11:54 UTC
What is the nfs server in this case?  Invalid filehandles are typically a server

Comment 3 ratness 2001-05-18 23:37:29 UTC
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 20:01:02 UTC
Doesn't happen in the version from rawhide

Comment 5 ratness 2002-05-31 11:41:02 UTC
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 16:27:27 UTC
This appears to still be the case in 8.0 as well.

Comment 7 Karsten Hopp 2002-12-03 11:19:54 UTC
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 15:05:21 UTC
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.