maillock(3X) maillock(3X)
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 maildlock (const char *user, int retrycnt, const char *dir);
int mailunlock (void);
DESCRIPTION
The maillock and maildlock functions attempt to create a
lockfile for the user's mailfile. If a lockfile already
exists, maillock and maildlock assume 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 or maildlock). If the process that created the
lockfile is still alive, maillock and maildlock 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. maildlock uses the directory passed as its third
argument.
Files
/usr/lib/llib-lmail.ln
/usr/lib/libmail.a
/var/mail/*
/var/mail/*.lock
Return Values
The following return code definitions are contained in
maillock.h. Only L_SUCCESS is returned for mailunlock.
Copyright 1994 Novell, Inc. Page 1
maillock(3X) maillock(3X)
#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 */
NOTICES
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.
Copyright 1994 Novell, Inc. Page 2