Bug 40470

Summary:	vim saves to new inode, stomps on filehandles
Product:	[Retired] Red Hat Linux	Reporter:	ratness
Component:	vim	Assignee:	Karsten Hopp <karsten>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	bcrl
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-11-30 16:27:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 
effects.

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
problem.

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.