home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 4614 < prev    next >
Encoding:
Text File  |  1992-08-23  |  2.8 KB  |  78 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!ugle.unit.no!lise.unit.no!arnej
  3. From: arnej@Lise.Unit.NO (Arne Henrik Juul)
  4. Subject: Re: lockd on 386BSD
  5. Message-ID: <1992Aug24.033540.11335@ugle.unit.no>
  6. Sender: news@ugle.unit.no (NetNews Administrator)
  7. Reply-To: arnej@lise.unit.no
  8. Organization: Norwegian Institute of Technology
  9. References: <BtFxC8.3r0@chinet.chi.il.us> <1992Aug23.205117.5204@fcom.cc.utah.edu>
  10. Date: Mon, 24 Aug 92 03:35:40 GMT
  11. Lines: 65
  12.  
  13. In article <1992Aug23.205117.5204@fcom.cc.utah.edu>,
  14.  terry@cs.weber.edu (A Wizard of Earth C) writes:
  15.  > In article <BtFxC8.3r0@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
  16.  > >
  17.  > >    Well, still no luck in being able to ">>" (append) properly
  18.  > >    to a BSD partition NFS mounted to my Dell system.  Tried all
  19.  > >    sorts of different mount options, tried different shells, etc.
  20.  > >    Append works ok on a Novell 3.11 mounted NFS partition, and another
  21.  > >    SYSVR4 (AT&T) system.  Now, I have noticed that 386BSD is not
  22.  > >    running any sort of lock daemon, i.e. lockd.  Not even any mention
  23.  > >    of it in any of the man pages having to do with NFS.
  24.  > >    Is this normal?
  25.  > 
  26.  > 1)    lockd is an addon.  It's normal to not have it.  You may want to
  27.  >     add it on, though.
  28.  
  29. But you probably don't want to write it, I don't :-)
  30. NFS and file locking are - well - somewhat anathema.
  31.  
  32.  
  33.  > 2)    The append failure is not a result of NFS.  It's a result of a rather
  34.  >     loose interpretation of the "a" and "a+" modes in POSIX 1003.1.  You
  35.  >     would be better off fixing the shell, or you're bound to repeat the
  36.  >     performance later with some other box.
  37.  
  38. I do not understand this comment - would you care to explain further?
  39. I have read the Standards (1003.1 and ANSI C), and they seem pretty
  40. clear to me.
  41.  
  42. Anyway, I will assert that it IS an NFS problem. The following
  43. program:
  44.  
  45.  
  46. #include <sys/file.h>
  47. main() 
  48. {
  49.   int fd;
  50.   
  51.   fd=open("afile", O_CREAT|O_WRONLY|O_APPEND);
  52.   write(fd, "testing\n", 8);
  53.   close(fd);
  54. }
  55.  
  56.  
  57. Will truncate the file "afile" when you mount FROM an NFS server on a
  58. 386bsd system ON some operating systems (at least SunOS seems to have
  59. this problem, and probably lots more).
  60.  
  61. This is a bug *somewhere* in NFS, and the big question is: SunOS or
  62. 386bsd?  Personally I'd bet that SunOS was the problem here, but
  63. that's only my gut feeling that Sun are unable to implement their own
  64. protocols according to spec.
  65.  
  66. The problem does NOT occur when I use the file system via NFS from a
  67. system running Ultrix, or from a m88k system running System Vr3.2.
  68.  
  69. We also have nearby a box running DEC OSF v1.0, which I *think* has the
  70. same problem, but I am unable to test this just now.
  71.  
  72. I hope that someone will be able to trace this one down, but if not,
  73. I'll have a go at it sometime next week.
  74.  
  75. Regards,
  76.  
  77. Arne H. Juul  --  arnej@lise.unit.no  --  University of Trondheim, Norway
  78.