rreport gagging on lockfile

John Esak john at valar.com
Wed Feb 3 14:01:39 PST 2010


Oh, Ken... I actually totally agree.  But, I was *assuming* that this
routine is done at a time when it is clear there should NOT be a lockfile.
If that is not so, then you are completely right. However, there are enough
times when errant lockfiles are created as you *first* said in this thread
by someone backing out badly or crashing out.  This happens a whole lot..
.and if on Saturday night your scripts have to run no matter what. Then,
removing lockfiles where you know it can do no harm, is reasonable. If it
isn't, what is the better suggestion?  Do people need to be logging in
before there periodic routines run, just to make sure no one is still in the
file and locking it in error.  I suppose that is the safest kind of thing.
But, if one needs to run a non-invasive report that just gathers data and
there are people left in the file who have gone home and such... It doesn't
seem like a bad work-around.  In any case, I must admit I've been doing it
for years and years without any problems.  Of course, as I say, I only do it
when I know removing the lock file won't cause any problems.

I should have put all that as a caveat when suggesting it.... 

John
 

> -----Original Message-----
> From: Kenneth Brody [mailto:kenbrody at gmail.com] 
> Sent: Wednesday, February 03, 2010 4:49 PM
> To: john at valar.com
> Cc: filepro-list at lists.celestial.com
> Subject: Re: rreport gagging on lockfile
> 
> On 2/3/2010 4:19 PM, John Esak wrote:
> [...]
> > I vote with your colleague
> >
> > rm -f ${PFDIR}/filepro/filename/lockf*
> >
> > at the head of your script and you will never see this 
> problem again.  On to
> > more agonizing problems.
> [...]
> 
> Such as cleaning up the corruption caused by removing the 
> lockfile while 
> someone was actually doing something in the file that you 
> shouldn't mess with?
> 
> Blindly removing lockfiles because you "need" to do something 
> "now" is just 
> asking for trouble.
> 
> -- 
> Kenneth Brody
> 



More information about the Filepro-list mailing list