Run fsx with -RW. (smbfs does not implement consistency between
	read-write access on the one hand, and mmap access on the other;
	using fsx -R -W avoids testing for those (known) bugs.)

	When  fsx issues the  sequence of operations:
	    1.  write data, X.
	    2.  truncate file down below X.
	    3.  truncate file back above upper edge of X.
	    4.  read from offset of prior data X

	then smbfs passes back the old prior file content, X,
	when it should instead return zeroes.

Fix: The patch below could be described as a "hot glue gun" approach; but
its also a thorough, suspenders-and-braces fix for this problem
(which, btw, does not occur in the NetBSD version of smbfs.)

I'm not really au-fait with the FreeBSD VM system, so I examined the
FreeBSD-4 NFS client code (taken from FreeBSD 4.7's sys/nfs as at
around April 2002) for the corresponding scenario under NFS;, and
patched similar handling into the smbfs code. it may well be that not
all the changes below are necessary; but they appear sufficient.

This patch also applies cleanly to FreeBSD 4-stable as recent up to as
recent as 4.9-STABLE January 2004; for me, it fixes the reported
problem on all those releases.  (If the problem is already fixed
elsewhere in 4.x, I didn't notice).


The timestamps on the diff below are genuine. Someone more familiar
with the 4-STABLE NFS code might wish to subsequent later fixes into
this patch; or reconstruct a similar fix starting from more recent
4-STABLE NFS code.   I can't speak to FreeBSD-5.


How-To-Repeat: 
	repeat as above using fsx.