Go forward to Execution File Format.
Go backward to UUCP Grades.
Go up to Protocols.

UUCP Lock Files

   This discussion applies only to Unix.  I have no idea how UUCP locks
ports on other systems.

   UUCP creates files to lock serial ports and systems.  On most, if not
all, systems, these same lock files are also used by `cu' to coordinate
access to serial ports.  On some systems `getty' also uses these lock
files, often under the name `uugetty'.

   The lock file normally contains the process ID of the locking
process.  This makes it easy to determine whether a lock is still
valid.  The algorithm is to create a temporary file and then link it to
the name that must be locked.  If the link fails because a file with
that name already exists, the existing file is read to get the process
ID.  If the process still exists, the lock attempt fails.  Otherwise
the lock file is deleted and the locking algorithm is retried.

   Older UUCP packages put the lock files in the main UUCP spool
directory, `/usr/spool/uucp'.  HDB UUCP generally puts the lock files
in a directory of their own, usually `/usr/spool/locks' or `/etc/locks'.

   The original UUCP lock file format encodes the process ID as a four
byte binary number.  The order of the bytes is host-dependent.  HDB UUCP
stores the process ID as a ten byte ASCII decimal number, with a
trailing newline.  For example, if process 1570 holds a lock file, it
would contain the eleven characters space, space, space, space, space,
space, one, five, seven, zero, newline.  Some versions of UUCP add a
second line indicating which program created the lock (`uucp', `cu', or
`getty/uugetty').  I have also seen a third type of UUCP lock file
which does not contain the process ID at all.

   The name of the lock file is traditionally `LCK..' followed by the
base name of the device.  For example, to lock `/dev/ttyd0' the file
`LCK..ttyd0' would be created.  On SCO Unix, the lock file name is
always forced to lower case even if the device name has upper case

   System V Release 4 UUCP names the lock file using the major and minor
device numbers rather than the device name.  The file is named
`LK.XXX.YYY.ZZZ', where XXX, YYY and ZZZ are all three digit decimal
numbers.  XXX is the major device number of the device holding the
directory holding the device file (e.g., `/dev').  YYY is the major
device number of the device file itself.  ZZZ is the minor device
number of the device file itself.  If `s' holds the result of passing
the device to the stat system call (e.g., `stat ("/dev/ttyd0", &s)'),
the following line of C code will print out the corresponding lock file
         printf ("LK.%03d.%03d.%03d", major (s.st_dev),
                 major (s.st_rdev), minor (s.st_rdev));
   The advantage of this system is that even if there are several links
to the same device, they will all use the same lock file name.

   When two or more instances of `uuxqt' are executing, some sort of
locking is needed to ensure that a single execution job is only started
once.  I don't know how most UUCP packages deal with this.  Taylor UUCP
uses a lock file for each execution job.  The name of the lock file is
the same as the name of the `X.*' file, except that the initial `X' is
changed to an `L'.  The lock file holds the process ID as described