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.
repeat as above using fsx.
I am the current smbfs maintainer.
Unassign due to lack of time.
Over to maintainer(s).
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped