Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!ptsfa!gilbbs!mc68020
From: mc68020@gilbbs.UUCP (Thomas J Keller)
Newsgroups: net.bugs.uucp
Subject: Re: uucico/uuxqt bugs...howcome?
Message-ID: <916@gilbbs.UUCP>
Date: Wed, 17-Sep-86 18:33:09 EDT
Article-I.D.: gilbbs.916
Posted: Wed Sep 17 18:33:09 1986
Date-Received: Fri, 19-Sep-86 23:05:54 EDT
References: <900@gilbbs.UUCP> <612@pyramid.UUCP> <914@gilbbs.UUCP> <614@pyramid.UUCP>
Organization: Gil's Place, Santa Rosa CA
Lines: 40
Summary: i am an egg

In article <614@pyramid.UUCP>, csg@pyramid.UUCP (Carl S. Gutekunst) writes:
> In article <914@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes:
> >   Yes, well.  I have now had innumerable responses to my queries regarding
> >XQT lock files.  Many people have suggested touching the file from cron.  AS
> >it happens, that doesn't work.
> >
> >   According to a contact at a site with source license, UUCP checks the
> >CREATION time, as opposed to the modification time of the lock file.
> 
> Your contact with a source license should learn to read man pages. :-)
> 
> This gets hashed out in unix-wizards every six months or so: there's no such
> thing as "creation time." UUCP checks ctime, which is the the "last status
> change time," literally the last time the inode changed. Since pretty darn
> near anything you can do to a file changes the inode, touching the lock file
> works just fine.
> 

   Well, i am an egg.  I will not presume to argue with someone of Carl's
experience regarding UNIX internals.  All I can say is that when I had a
shell script merely "touching" my XQT lock file, I occasionally still wound 
up with additional XQT processes running (sometimes with as little as a few
minutes between start-times).  When I altered my script to actually COPY the
lock file, remove the original and copy the copy back to the original name
again (all with a nice --10 in front of it) the problem seems to have gone
away.

   I am going to remove news unbatching from the purvue of uuxqt, which is
a better approach anyway.  

   Thanks to everyone for their assistance and patience.

-- 

Disclaimer:  Disclaimer?  DISCLAIMER!? I don't need no stinking DISCLAIMER!!!

tom keller					"She's alive, ALIVE!"
{ihnp4, dual}!ptsfa!gilbbs!mc68020

(* we may not be big, but we're small! *)