HDB style locks (was "kermit")
Note: I have carbon copied this to the FSSTND mailing list since it
provides an "above average" explanation of HDB format lock files.
It also corrects a completely incorrect interpretation of the Taylor
UUCP "policy.h" file. Tremendous apologies to all.
--
Robert Sanders <gt8134b@acme.gatech.edu> writes:
> 1) The lock files, while in the correct place, are not of the correct
> format. The pid is stored in binary format, while the fsstnd 1.0
> requires that the lock file format be "HDB style ... locking process ID
> in ASCII, padded with leading zeroes to ten characters, followed by a
> newline." A small patch to ckutio.c was required to force the leading
> zeroes. Does anyone sure that HDB UUCP *requires* the leading 0's?
This is from the Taylor UUCP Info format docs which are available at
/ftp@prep.ai.mit.edu:/pub/gnu/uucp-doc-1.04.1.tar.gz
-------------------- cut here ----------------------------------------
The original UUCP lock file format encoded the process ID as a four
byte binary number. The order of the bytes was 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). I have also seen a third type of UUCP lock file which did not
contain the process ID at all.
The name of the lock file is generally "LCK.." followed by the base
name of the device. For example, to lock /dev/ttyd0 the file
LCK..ttyd0 would be created. There are various exceptions. On SCO
Unix, the lock file name is always forced to lower case even if the
device name has upper case letters. System V Release 4 UUCP forms the
lock file name using the major and minor device numbers rather than
the device name (this is pretty sensible if you think about it).
-------------------- cut here ----------------------------------------
FSSTND decided against the SCO and SVR4 implementations for various
reasons.
The next release of FSSTND will correct for the zero/space error.
Dan
--
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Reply to: