>Number:         1697
>Category:       bin
>Synopsis:       vi uses mmap() instead of read(); can corrupt remote files
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 26 18:20:01 1995
>Last-Modified:
>Originator:     David Eckhardt
>Organization:
Carnegie Mellon University Computer Science
>Release:        NetBSD-0812
>Environment:
	System: NetBSD piper.nectar.cs.cmu.edu 1.0A NetBSD 1.0A (IJET) #152: Sat Jul 15 14:38:58 EDT 1995 kosak@river:/usr/src/sys/arch/i386/compile/IJET i386
	vi: Version 1.34, Wed Aug 17 14:37:48 1994

>Description:
	vi seems to use mmap() instead of read() on files being edited.  This
	is bad because mmap() of a file from a remote file system (in this case
	AFS 3.0 1.6, but also NFS) is not consistent.  That is, while metadata
	such as modification time and length are obtained correctly from the
	filesystem, the data pages in memory objects are NOT updated when the
	remote file changes.  I have just repeated this with two NetBSD/i386
	laptops (-current) running NFS but not AFS, so it is NOT an AFS problem.

>How-To-Repeat:
	on machine A
	echo foo > /afs/some/file

	on machine B (NetBSD i386, AFS 3.0 revs 1.20, 1.26)
	vi /afs/some/file
	(see screen with foo, ~'s)
	(don't quit)

	on machine A
	echo bar >> /afs/some/file

	on machine B
	:e
	(see foo, nulls, ~'s)
	:q
	cat /afs/some/file
	(see foo, bar)
	!vi
	(see foo, nulls again)

	From running ktrace on vi, I believe that the problem is that vi is
	using fstat() to get the (new) length of the file but using mmap()
	to get the (old) contents.

>Fix:
	Either (1) get vi to stop using mmap() or (2) get mmap() to do the
	right thing.  Since this problem can result in file corruption (if
	you don't notice the wrong part you will write it out and it will
	become the "correct" file contents, which actually happened to me),
	I think this is severe.
>Audit-Trail:
>Unformatted: