home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 418 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  1.6 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: henry@zoo.toronto.edu (Henry Spencer)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: File Locking across NFS mounts
  5. Date: 10 Sep 1992 16:40:00 -0700
  6. Organization: U of Toronto Zoology
  7. Lines: 24
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <18omcgINN8tm@ftp.UU.NET>
  11. References: <18j4hdINNdst@ftp.UU.NET> <18lpndINN8ti@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  16.  
  17. >Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  18. >The time-honored technique of using a directory as a semaphore and using
  19. >mkdir() and rmdir() as lock and unlock works fairly well, although it's
  20. >rather slow...
  21.  
  22. It isn't reliable, however.  The crucial point is that NFS does not provide
  23. a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
  24. have not seen details and don't have a reference -- that if you look hard
  25. enough at the problem, and consider things like finite cache sizes, you
  26. can prove that there is *no way* to do reliable locking through the NFS
  27. protocol.  You have to use some sort of non-filesystem method, like
  28. locking daemons (and I agree with John that writing your own is the best
  29. method; the existing ones are garbage).
  30.  
  31. This is one reason (of many) why proposals to canonize NFS as a standard
  32. weren't greeted with cries of delight from all directions...
  33. -- 
  34. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  35. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  36.  
  37.  
  38. Volume-Number: Volume 29, Number 30
  39.