home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / mail / mh / 1375 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.8 KB  |  64 lines
  1. Newsgroups: comp.mail.mh
  2. Path: sparky!uunet!uaisun4!mrl
  3. From: mrl@uai.com (Mark R. Ludwig)
  4. Subject: Re: Question on Locking ...
  5. In-Reply-To: paul@engin.umich.edu's message of Thu, 10 Dec 92 18:41:11 EST
  6. Message-ID: <MRL.92Dec14063227@sun4.uai.com>
  7. Sender: mrl@uai.com (Mark R. Ludwig)
  8. Organization: Universal Analytics, Inc., Torrance (LA), CA
  9. References: <fAR=jkB@engin.umich.edu>
  10. Date: 14 Dec 92 06:32:27
  11. Lines: 51
  12.  
  13. In article <fAR=jkB@engin.umich.edu> paul@engin.umich.edu (Paul Killey) writes:
  14.  
  15. |> It seems like Sun's style of locking one's mailbox is to link a
  16. |> tempfile in /usr/spool/mail to /usr/spool/mail/user.lock.
  17.  
  18. Yes, I believe this is so.  It also uses one of the kernel's advisory
  19. locking facilities (lockf() or flock()), but I forget which.  Despite
  20. delivering a non-working rpc.lockd all these years, I believe Sun
  21. still recommends using NFS for the mail spool, so I suspect the call
  22. they use is lockf().  If NFS really is involved, then all the better
  23. to hang your network at random, my dear.
  24.  
  25. |> I presume this is to make things more robust when you NFS mount
  26. |> your /usr/spool/mail.
  27.  
  28. I presume you are correct.  I suppose if a fixed rpc.lockd ever
  29. actually makes it into all the vendors' deliveries, it might actually
  30. be reasonably robust to NFS-mount the mail spool.
  31.  
  32. |> Would inc do this sort of lock if LOK_BELL were used, and lockldir were
  33. |> made /usr/spool/mail?  If someone could say, it would save me some time
  34. |> and effort.
  35.  
  36. I don't know what LOK_BELL is, but the mh-tailor(5) documentation I
  37. have (6.7.2) implies that "lockstyle: 1" will do this.
  38.  
  39. |> What about just pitching the Sun Mail and /bin/mail, using Mail and
  40. |> /bin/mail done from source, and using flock()?  Accessing
  41. |> /usr/spool/mail via NFS is not under consideration here.
  42.  
  43. That's fine too.  Just make sure that all the programs which can
  44. access the mail spool agree on the locking method.  That's all that
  45. matters.
  46.  
  47. |> There is also the consideration of getting popper, imapd, and the
  48. |> sundry other programs that update /usr/spool/mail all agreeing on
  49. |> locking.
  50.  
  51. Yes.  I'm in the process of making POP the only access method, and
  52. moving mail out of the spool to enforce it (actually just another
  53. directory under /usr/spool).  This will make the "standard" mail
  54. utilities never work because they won't know where the mail is.  I'm
  55. planning to use flock() for locking, because this is a Sun, and I
  56. don't have much confidence in lockf() until such time as Sun stops
  57. patching rpc.lockd.  I'm planning to use Chip's "deliver" and the popd
  58. from the MH distribution; I wonder if I should look into popper?  I
  59. someone would comment on this, I'd appreciate it.$$
  60. -- 
  61. INET: mrl@uai.com           NIC: ML255           ICBM: USA; Lower Left Coast
  62. "A computer is one of life's joys; it follows simple rules.  Just like
  63.  children, adults need toys, only we like to call them 'tools.'" -- Dave Ross
  64.