Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!labtam!labtam!iand
From: iand@labtam.labtam.oz.au (Ian Donaldson)
Subject: Re: lockd on 386BSD
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Mon, 24 Aug 1992 04:34:43 GMT
Message-ID: <iand.714630883@labtam>
References: <BtFxC8.3r0@chinet.chi.il.us> <1992Aug23.205117.5204@fcom.cc.utah.edu> <1992Aug24.033540.11335@ugle.unit.no>
Lines: 29
arnej@Lise.Unit.NO (Arne Henrik Juul) writes:
>Anyway, I will assert that it IS an NFS problem. The following
>program:
> fd=open("afile", O_CREAT|O_WRONLY|O_APPEND);
>Will truncate the file "afile" when you mount FROM an NFS server on a
>386bsd system ON some operating systems (at least SunOS seems to have
>this problem, and probably lots more).
>This is a bug *somewhere* in NFS, and the big question is: SunOS or
>386bsd? Personally I'd bet that SunOS was the problem here, but
>that's only my gut feeling that Sun are unable to implement their own
>protocols according to spec.
I fixed this exact bug in an ancient NFS port a few days ago (on a SVR3.2
machine actually). The problem was that the NFS server wasn't interpreting
the sattr information provided in the "NFS create" call properly.
One field of sattr is the file size. When you do creat() of the above
form, SunOS sends the file size attribute as -1 over the wire which should
mean to the server "don't change the file size". The server is probably
ignoring this field and truncating the file unconditionally (at least thats what
the server I worked on did).
The fix was trivial... just recognize the size attribute and if -1, leave
the file size alone, otherwise truncate to the specified value.
Ian D