home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.bsd
- Path: sparky!uunet!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
-