home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 409 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  1.9 KB

  1. Xref: sparky comp.std.unix:409 comp.unix.programmer:4573
  2. Path: sparky!uunet!uunet!not-for-mail
  3. From: lebrun@ll.mit.edu ("Steven F. LeBrun")
  4. Newsgroups: comp.std.unix,comp.unix.programmer
  5. Subject: File Locking across NFS mounts
  6. Followup-To: comp.unix.programmer
  7. Date: 8 Sep 1992 14:04:45 -0700
  8. Organization: MIT Lincoln Laboratory, Lexington, MA
  9. Lines: 32
  10. Sender: sef@ftp.UU.NET
  11. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  12. Expires: 25 Sep 1992
  13. Message-ID: <18j4hdINNdst@ftp.UU.NET>
  14. NNTP-Posting-Host: ftp.uu.net
  15. X-Submissions: std-unix@uunet.uu.net
  16.  
  17. Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
  18.  
  19. I am looking for a method of file locking what works across NFS
  20. mounted directories and am interested on what methods other 
  21. people are using.
  22.  
  23. I tried flock() and discovered a bug that only exists if the file 
  24. being locked is a remote (NFS) file.  If a program terminates without 
  25. unlocking an NFS file (due to a system reboot, user abort, program 
  26. bug [this is how I discovered the problem -- bugs can be useful at 
  27. times :-) etc.] the file remains locked so that no other programs 
  28. can access the file.
  29.  
  30. The programs that access the file are running on different computers 
  31. with the same file accessible via NFS mounts.  Currently, the programs 
  32. are all running on SGI Indigo's (IRIX 4.0.1) and other computers of 
  33. unknown type will be added later.  I would prefer staying with advisory 
  34. file locking but manditory file locking is an option.  Since the file
  35. being locked is a log/audit trail file that the programs append their
  36. next entries, locking the entire file is acceptable.  Locking the next
  37. local record (next entry) and the entire file will have the same 
  38. effect on the programs accessing the file.
  39.  
  40.  
  41. --
  42. Steven F. LeBrun
  43. lebrun@ll.mit.edu
  44.  
  45. [ Note crosspostings, and Followup line.  Feel free to post any followups
  46.   here (comp.std.unix) if you feel it relevent. -- mod ]
  47.  
  48. Volume-Number: Volume 29, Number 21
  49.