From:    Joao Carlos Mendes Luis <jonny@gaia.coppe.ufrj.br>
	Subject:  VI is crazy !!!
	Date:    Thu, 29 Feb 1996 21:41:09 -5100 (EST)

	I don't know what else I could do.  Our VI editor is misbehaving
	strangely and I don't know why.  Here are the symptoms:
	
	If I edit an existing file, add a new line in the middle, and save it,
	the saved file will be corrupted.  The *exact* number os characters
	added will be added to the file a ^@ (ascii 0) at the end of the file,
	but all the remaining text is still unchanged.  There are other symptoms,
	but this is the most frequent.  Oh, and this one is even stranger: Once
	I did look at the saved file with od -c, and THE MODIFICATIONS WERE THERE.

There is a known problem in NetBSD that has these symptoms.  Basically,
the NetBSD vi uses mmap() instead of read() to get its file data.  When
you call mmap(), you get access to a "memory object" which in turn gets
pages from the file system buffer cache.  As long as you store the
information back via the memory object, all is well, but if the file is
changed by the file system (somebody else does write() or it is changed
on a remote fileserver), the memory object never hears about it, so you
have two different versions of the file, one which mmap() will see and
one which read() will see.  Even more interesting, stat() sees the same
version read() does, so vi knows the new file *size* but can't get the
*bytes*, and ^@ gets substituted in for sensible but unimportant
reasons.

	Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
	/dev/sd0a      198335    96318    92100    51%    /
	/dev/sd0e     1442718  1228406   142176    90%    /usr
	/usr/home     1442718  1228406   142176    90%    /home
	kernfs              1        1        0   100%    /kern
	procfs              4        4        0   100%    /proc

You don't seem to be using a remote filesystem, but you do seem to have
/dev/sd0e mounted twice, maybe via a loopback filesystem?  I bet that
if you stop doing that all will be well.  Your other options are fixing
the kernel (and getting the fix adopted), getting vi to stop using
mmap() (which I think would involve pretty minor hacking of the db
package and recompilation), suffering, or not using vi.

Dave
P.S. I currently suffer, but was once on the verge of hacking db.
If anybody else has or does, let us know.