#define quoting(David_Eckhardt@ROBIN.WARP.CS.CMU.EDU)
// 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
// 
// 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

The /home directory was a mount -t null.  Removing it solved my problem.
Thanks a lot for your help...

To fix the kernel is somewhat out of my possibilities.  Maybe when,
someday, Net and FreeBSD folks get joined again this (and some other
small problems on both sides) get fixed.

					Jonny

--
Joao Carlos Mendes Luis			jonny@coe.ufrj.br
+55 21 290-4698 ( Job )			jonny@cisi.coppe.ufrj.br
Network Manager				UFRJ/COPPE/CISI
Universidade Federal do Rio de Janeiro