Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!decwrl!sgi!roberts@nimrod.wpd.sgi.com
From: roberts@nimrod.wpd.sgi.com (roberts)
Newsgroups: comp.sys.sgi
Subject: Re: Why was mail_bsd(1) changed?
Message-ID: <84074@sgi.sgi.com>
Date: 5 Feb 91 16:29:20 GMT
References: <1991Jan24.185356.13375@alias.uucp> <83600@sgi.sgi.com> <1991Feb4.175108.9761@alias.uucp>
Sender: guest@sgi.sgi.com
Distribution: na
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 64

In article <1991Feb4.175108.9761@alias.uucp>, mark@alias.uucp (Mark Andrews) writes:
>
> 	FILE			Reason
> 	----			------
> 
>      /usr/mail/user.lock      Lock for user's mailbox.
>      /usr/mail/user.rolock    Read-only lock for user's mailbox.
>                               Used to prevent file contention between multiple
>                               Mail instances.
> 
> Under what circumstances are these files created by mail_bsd(1)?
> 
> I suspect that the `user.lock' file is only created by the mail program which
> delivers the mail to a users mailbox. Does SGI's version of mail_bsd(1) care
> about the existence of this file?

Yes.  This file is (should be) created and respected by any program which reads
or modifies a mail file.  The file will exist whenever /bin/mail or BSD Mail
is reading or modifying the contents of the mailfile.  Both /bin/mail and BSD
Mail check for the existance of this lock file before reading or modifying the
mail file.

>				     I know from prior releases that if
> /usr/mail/user.lock existed when that user logged in, their login session would
> be locked until the user.lock file was removed (i.e.: the `/bin/mail -e' test
> in /etc/cshrc). I seem to remember reading about something in the IRIX 3.3
> or 3.3.1 release notes that SGI had fixed this problem, but I don't remember.
> What should mail_bsd(1) do if it encounters a user.lock file?

Yes, the problem you mentioned has been solved.

The user.lock file contains the PID of the process which created it.  If BSD
Mail encounters a user.lock file containing the PID of an active process, it
will sleep and check again every 5 seconds.  If 5 minutes elapse and the
user.lock file has not disappeared, or the process which created it has not
died, BSD Mail will assume that the user.lock file is bogus (since any user.lock
file should be short-lived) and will overwrite it with its own user.lock file
containing its own PID.

Note, a similar mechanism is used by /bin/mail.

> The purpose of the user.rolock is probably exactly as it looks. When you enter
> mail_bsd(1), the rolock file is created, thus making the users mail file
> read-only. As long as /usr/mail/user.rolock exists, the file may not be
> modified. If an attempt is made to modify the mail file (i.e.: concurrent mail
> sessions), the program should warn the user that the file may not be modified
> at this time.

You are correct.

> There is also the point that mail_bsd(1) is setgid mail, while BSD mail was
> not.

This is so that the lock files can be written into the /usr/mail directory.
Pre-3.3 BSD Mail did not create user.lock files correctly, and there was a
possibility for corruption of the mailbox if you were quitting Mail at the
same time that /bin/mail was delivering a message.  The problem with writing
proper lock files also contributed to the login session lock-up problem
of pre-3.3 systems.

	- Robert Stephens
	  Silicon Graphics Inc.

	  roberts@sgi.com