On Thu, Aug 16, 2001 at 10:18:58AM +0100, Konstantin Chuguev wrote:
>
> I'd say, it's a daemon pretending to be an NFS server. It's running
> locally on port other than NFS.
>
> Very nice implementation, I use it a lot. A small problem with it is
> that it seems to support 7-bit file names only.
I tracked down tonight the one other problem with cfs that has plagued
me repeatedly (although it hasn't prevented me from using it day in and
day out with a couple of shell scripts to fix-up mail files corrupted by
this bug).
There is a rather serious bug in cfs that causes it to throw away writes
when those writes append to the file, are smaller than the blocksize (8
bytes by default), and would otherwise leave the file a multiple of the
blocksize. In this situation, the file needs to be truncated (due to
the padding scheme in use), but cfs doesn't truncate and the file
appears unchanged after the write.
Patches have been sent to [EMAIL PROTECTED] and I submitted a
separate PR[1] to get the patch into ports until a new cfs release hits
the street. I've attached a copy of that patch since the readers of
this thread seem to be using cfs.
cheers,
--Scott
[1] http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30120
--
Scott Renfro <[EMAIL PROTECTED]>
--- cfs_fh.c.orig Mon Aug 27 01:47:52 2001
+++ cfs_fh.c Mon Aug 27 01:48:41 2001
@@ -177,6 +177,13 @@
perror("write");
return -1;
}
+ /* due to the way the file is padded we may actually have to
+ truncate it here. This happens when the write is at the end of
+ the file, is shorter than CFSBLOCK and brings the file to a length
+ which is evenly dividable by CFSBLOCK */
+ if (offset+len > dtov(sb.st_size) && vtod(offset+len) < sb.st_size) {
+ ftruncate(fd, vtod(offset+len));
+ }
/* iolen may contain CFSBLOCK extra chars */
return(dtov(iolen)-fronterr);
}
