🚀 go-pugleaf

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! *)