Amiga Unix — 68040 · 68060

Manual pages › X Window and screen libraries (3X)

maillock(3X)

manage lockfile for user's mailbox

From the original Amiga UNIX 2.1 manual. Some things it mentions may not be in this release.

NAME

maillock - manage lockfile for user's mailbox

SYNOPSIS

cc [flag ...]  file  ...   -lmail  [library  ...]   #include
<maillock.h>  int maillock (const char *user, int retrycnt);
int mailunlock (void);

DESCRIPTION

The maillock function attempts to create a lockfile for the user's mailfile. If a lockfile already exists, maillock assumes the contents of the file is the process ID (as a null-terminated ASCII string) of the process that created the lockfile (presumably with a call to maillock). If the process that created the lockfile is still alive, maillock will sleep and try again retrycnt times before returning with an error indication. The sleep algorithm is to sleep for 5 seconds times the attempt number. That is, the first sleep will be for 5 seconds, the next sleep will be for 10 seconds, etc. until the number of attempts reaches retrycnt. When the lockfile is no longer needed, it should be removed by calling mailunlock.

user is the login name of the user for whose mailbox the lockfile will be created. maillock assumes that users' mailfiles are in the ``standard'' place as defined in maillock.h.

RETURN VALUE

  The following  return  code  definitions  are  contained  in
  maillock.h.
#define   L_SUCCESS    0   /* Lockfile created or removed */
#define   L_NAMELEN    1   /* Recipient name > 13 chars */
#define   L_TMPLOCK    2   /* Can't create tmp file */
#define   L_TMPWRITE   3   /* Can't write pid into lockfile */
#define   L_MAXTRYS    4   /* Failed after retrycnt attempts */
#define   L_ERROR      5   /* Check errno for reason */

FILES

LIBDIR/llib-mail.ln
LIBDIR/mail.a
/var/mail/*
/var/mail/*.lock

NOTES

mailunlock will only remove the lockfile created from the most previous call to maillock. Calling maillock for different users without intervening calls to mailunlock will cause the initially created lockfile(s) to remain, potentially blocking subsequent message delivery until the current process finally terminates.