home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 4693 < prev    next >
Encoding:
Text File  |  1992-08-25  |  2.5 KB  |  54 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!kent
  3. From: kent@sparky.imd.sterling.com (Kent Landfield)
  4. Subject: Re: lockd on 386BSD
  5. Message-ID: <1992Aug25.214437.12699@sparky.imd.sterling.com>
  6. Organization: Sterling Software
  7. References: <BtFxC8.3r0@chinet.chi.il.us> <1992Aug23.205117.5204@fcom.cc.utah.edu> <BtHnEo.GpE@chinet.chi.il.us>
  8. Date: Tue, 25 Aug 1992 21:44:37 GMT
  9. Lines: 42
  10. X-Md4-Signature: 7fa61a2eec82b99dfd8e79d02889d7e7
  11.  
  12. In article <BtHnEo.GpE@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
  13. >In article <1992Aug23.205117.5204@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
  14. >>2)    The append failure is not a result of NFS.  It's a result of a rather
  15. >>    loose interpretation of the "a" and "a+" modes in POSIX 1003.1.  You
  16. >>    would be better off fixing the shell, or you're bound to repeat the
  17. >>    performance later with some other box.
  18. >
  19. >    Problem is, it is not just the shell.  I use the archive program,
  20. >    rkive to archive the sources groups.  I used to have the archives
  21. >    directory mounted on my main system.  Now that the archives file
  22. >    system has grown to over 200 megs (os2 is a prolific os!)
  23. >    I mounted it on the BSD system.  Since then, nothing but garbage.
  24. >    rkive appends to log, index and a few other house keeping files.
  25. >    All these files are complete garbage since moving to BSD.
  26. >    I temporarily moved the archive to my Novell 3.11/NFS system, and
  27. >    things are fine.
  28.  
  29. The problem is not rkive's.  Yeah, right.. You knew I'd say that... :-) But
  30. it isn't.  Archives have been maintained by rkive via NFS in quite a few 
  31. places, on different platforms and have been for years now.  
  32.  
  33. >> The particular ambiguity I am referring to was discussed here before;
  34. >> in particular, if you open a file in append mode, the file pointer is
  35. >> set to the end of the file.  If you seek to a different offset prior
  36. >> to the EOF point, the seek places the pointer at EOF, not at the requested
  37. >> location.  In combination with the create flag, this can cause full
  38. >> truncation.
  39.  
  40. Rkive just opens the file a+ (why the '+ is there, I do not know but that is 
  41. another question) and does not move the file pointer. Just an open and a 
  42. fprintf().
  43.  
  44. This sounds like a real NFS daemon bug...
  45.  
  46. PS. I'm removing the '+' on the opens since its not needed.  Next release...
  47.  
  48.             -Kent+
  49. ---
  50. Kent Landfield                   INTERNET: kent@IMD.Sterling.COM
  51. Sterling Software, IMD           UUCP:     uunet!sparky!kent
  52. Phone:    (402) 291-8300         FAX:      (402) 291-4362
  53. Please send comp.sources.misc-related mail to kent@uunet.uu.net.
  54.