*BSD News Article 4057


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!mcsun!sunic!aun.uninett.no!ugle.unit.no!lise.unit.no!arnej
From: arnej@Lise.Unit.NO (Arne Henrik Juul)
Subject: Re: lockd on 386BSD
Message-ID: <1992Aug24.033540.11335@ugle.unit.no>
Sender: news@ugle.unit.no (NetNews Administrator)
Reply-To: arnej@lise.unit.no
Organization: Norwegian Institute of Technology
References: <BtFxC8.3r0@chinet.chi.il.us> <1992Aug23.205117.5204@fcom.cc.utah.edu>
Date: Mon, 24 Aug 92 03:35:40 GMT
Lines: 65

In article <1992Aug23.205117.5204@fcom.cc.utah.edu>,
 terry@cs.weber.edu (A Wizard of Earth C) writes:
 > In article <BtFxC8.3r0@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
 > >
 > >	Well, still no luck in being able to ">>" (append) properly
 > >	to a BSD partition NFS mounted to my Dell system.  Tried all
 > >	sorts of different mount options, tried different shells, etc.
 > >	Append works ok on a Novell 3.11 mounted NFS partition, and another
 > >	SYSVR4 (AT&T) system.  Now, I have noticed that 386BSD is not
 > >	running any sort of lock daemon, i.e. lockd.  Not even any mention
 > >	of it in any of the man pages having to do with NFS.
 > >	Is this normal?
 > 
 > 1)	lockd is an addon.  It's normal to not have it.  You may want to
 > 	add it on, though.

But you probably don't want to write it, I don't :-)
NFS and file locking are - well - somewhat anathema.


 > 2)	The append failure is not a result of NFS.  It's a result of a rather
 > 	loose interpretation of the "a" and "a+" modes in POSIX 1003.1.  You
 > 	would be better off fixing the shell, or you're bound to repeat the
 > 	performance later with some other box.

I do not understand this comment - would you care to explain further?
I have read the Standards (1003.1 and ANSI C), and they seem pretty
clear to me.

Anyway, I will assert that it IS an NFS problem. The following
program:


#include <sys/file.h>
main() 
{
  int fd;
  
  fd=open("afile", O_CREAT|O_WRONLY|O_APPEND);
  write(fd, "testing\n", 8);
  close(fd);
}


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.

The problem does NOT occur when I use the file system via NFS from a
system running Ultrix, or from a m88k system running System Vr3.2.

We also have nearby a box running DEC OSF v1.0, which I *think* has the
same problem, but I am unable to test this just now.

I hope that someone will be able to trace this one down, but if not,
I'll have a go at it sometime next week.

Regards,

Arne H. Juul  --  arnej@lise.unit.no  --  University of Trondheim, Norway