Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.questions
Subject: Re: Kermit vs uugetty
Summary: 11-byte undocumented restriction for lockfiles
Message-ID: <125@minya.UUCP>
Date: 28 Mar 90 03:37:41 GMT
References: <62@demott.COM> <1990Mar12.174721.13244@tcsc3b2.tcsc.com>
Lines: 35

> Well, I am going to guess that you might be using Un*x SVR3.2 or
> thereabouts.  HoneyDanBer uucp uses the directory /usr/spool/locks
> to keep lock files regarding what devices are in use, etc.  Many 
> early versions of kermit may use the /usr/spool/uucp directory
> for these lock files.  You basically need to modify kermit, if you
> have the sources, so that it uses the /usr/spool/locks directory
> instead.  The HDB version of uugetty should then keep its mouth
> shut when kermit creates a lock file such as 
> /usr/spool/locks/LCK..tty01.

You also need to know that there are many versions of HDB UUCP around that
have an undocumented restriction on the lockfiles:  they must be exactly 11
bytes long.  In fact, they must be of the format:
	fprintf(lkf,"%10d\n",getpid());

On systems whose UUCP has this restriction, the behavior when this rule is
not followed is simple and quite nasty:  the lockfile is silently deleted 
by whatever program notices it, and the program (uucico, uugetty, whoever) 
goes ahead and uses the port.

I first noticed this by stumbing across it just as you might guess.  As it
happened, I had the UUCP source available; it was my one of my jobs to port 
it to the machine.  I located the code that checked lockfiles and verified 
that it acted as I had surmised.  I was duly grossed out, of course, and 
offered to correct what I viewed as a serious bug.  Nope; my job was to port 
the code and get it running exactly like ATT thought it should run.    It 
wasn't my job to make unapproved and nonstandard modifications.

(I hope I'm not committing some serious criminal act by so divulging internal
details that I learned by reading the proprietary code. ;-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc

[Sorry, no clever saying today.]