indra@pepsi.amd.com (Indra Singhal) (04/14/90)
I have an environment that has a bunch of diskless workstations NFS mounting /var/spool/mail from a mail hub. It is therefore possible for a user to invoke elm both on his w/s and on the mail hub. While the consequences of such actions is known to all users, it would be nice if it was possible to prevent this from happening. One suggestion was to keep the temp file in the user's home directory instead of /tmp... but that has its shortcomings too. On a similar subject, when using elm to browse folders [elm -f foo] it is again possible to have multiple invocations of elm for the same folder. Does the community feel that locking folders is a good idea or should we let folks who err suffer? Finally, is the locking mechanism described somewhere? We have an office automation application, Alis [from Applix, Inc.] that has the ability to grab what it thinks is Alis mail from /usr/spool/mail/mymailbox. In doing so, it does not know to see if the file is being accessed (maybe by elm). Any pointer towards any doc. on the locking philosophy of elm would be helpful. I'd pass the info to Applix and hope they will fix Alis. Thanks much!! iNDRA | indra@amdcad.AMD.COM (Indra Singhal) (408) 749-5445 | {ames decwrl apple pyramid sun uunet}!amdcad!indra | MS 167; Box 3453; 901, Thompson Pl., Sunnyvale, CA 94088
syd@DSI.COM (Syd Weinstein) (04/14/90)
indra@pepsi.amd.com (Indra Singhal) writes: >I have an environment that has a bunch of diskless workstations NFS >mounting /var/spool/mail from a mail hub. It is therefore possible for >a user to invoke elm both on his w/s and on the mail hub. While the >consequences of such actions is known to all users, it would be nice if >it was possible to prevent this from happening. first off, file locking (flock) does not work over NFS, so all bets are off, but... >Finally, is the locking mechanism described somewhere? We have an >office automation application, Alis [from Applix, Inc.] that has the >ability to grab what it thinks is Alis mail from >/usr/spool/mail/mymailbox. In doing so, it does not know to see if the >file is being accessed (maybe by elm). Any pointer towards any doc. on >the locking philosophy of elm would be helpful. I'd pass the info to >Applix and hope they will fix Alis. Elm uses two locking methods, one an advisory lock and the other a mandatory lock. On systems that support flock, Elm will use it, This is a mandatory lock. The actual spool mailbox is locked for the duration of the time that Elm has it open (which is not very long). The spool is locked during the copy to the temporary file, and during the copy back to the spool file on resync or exit from Elm. It is this flock type lock that is not supported by NFS, thus it is not wise to mount /var/spool/mail via NFS. NFS cannot lock files because is it stateless. On systems that do not support flock, Elm uses the older standard of creating a file.lock file in the spool directory while it is reading or updating the spool file. In 2.2, both methods are used if flock is available. Under 2.3, you have a choice to use both or only flock if flock is available. The second type of lock, the advisiory lock is the creation of a mbox.user temp file. This lock prevents two copies of Elm from running on the same spool at the same time. This lock method is private to elm and is not honored by other products. It is up to the users to prevent more than one MUA from accessing the same spool file. The spool file itself is not locked during the entire session to allow for the delivery of mail during the session. Since only a MUA can delete mail from the spool, MTA's just append to the end of the spool, this method is safe from damage by the MTA. I hope this helps. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or bpa!dsinc!syd FAX: (215) 938-0235