Locked record

[John Esak]

I'll answer this, too... But it's a poor substitute for the horse's mouth.
However, the filePro lockfile is simply a Program-wide method for the
various filePro programs to know if a key file is opened by other filepro
program.  So, let's say someone goes into *clerk on a filePro file it ticks
the clerk flag high.  Now, someone else is going to try and run a report
against that same file... Perhaps wanting a total value from some field on
every record.  The logic was way back when, was that if someone is in the
clerk file, they could be *changing* a record, adding a record, deleting a
record while there in there... So don't let this person run their report
until the file has no one in it.  And, obviously, this is a very "rough"
approximation of the reasoning for a filePro lockfile of its own.  The
report program sees that the clerk flag is high and says okay don't run,
someone is using the file.  To bypass this warning mechanism (in other words
you want to run a  report regardless of whether anyone is in the file at the
time...) it can be bypassed by placing a "-u" on the [dr]report command
line.  Then the filePro lockfile is ignored.  You can easily see that this
whole methodology has absolutely nothing to do with the system based record
locking scheme, nada, zero, zip, zilch, etc. :-)

John

P.S. - The lock file is recreated fresh every time filePro executables
run... In other words if it's not there, it gets created. If it is there,
the associated byte for that executable is ticked up by one. And as the
programs back out they decrement their previous incrementing. (Which does
bring up the question of how do you account for more than 256 increments or
users of that program simultaneously...) I don't know.  Maybe the new larger
format lockfile allows higher user numbers than the previous 256?  By the
way, I'm just "assuming" that this incrmenting/decrmenting of the program's
particular byte is the way the old 64 byte lockfile was handled. The layout
for the 64 byte lockfile was on the website somewhere, I suppose the new
layout is there also, and it might do more in terms of user locking counts.


Since I am very aware of how the filePro lockfile works and what its purpose
is, I often want to bypass it completely before running a report, or trying
to get something done when it says I can't.... I'm usually the only person
running my programs these days and if it says someone's in the file and I
know I'm not... Then I just wholesale remove the lockfile itself and do what
I wanted to do. I'm not suggesting anyone ever do this... But in case you
hate going all the way into the filePro directory just to remove a
lockfile... You know you can do it by just deleting the "lockfile" file for
the particular filePro folder.

Also, if you want a brute force method for removing all lockfiles
immediately, I have always had a "nuke" script. If you see this in
/usr/local/bin on any *nix box... It kind of says John Esak has been here.
:-)  It merely has the following line in it:

Rm -f $PFDATA$PFDIR/filepro/*/lockf*

To do the same thing on Windows is a little trickier, you have to just use
the name "lockf*" and the /s recursive flag.  So the easiest thing is
something like:

Cd %PFDIR%\filepro
Erase /s lockf*

Or whatever puts you in the correct parent folder so you're not searching
through the entire fiel system for lockfiles.


Incidentally, the wildcard lockf* is used to ensure getting all the
qualified lockfiles as well as the unqualified "lockfile" itself.  Qualified
lockfiles are lockf[qualifier].



> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Fairlight
> Sent: Thursday, May 27, 2010 12:48 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Locked record
> 
> Four score and seven years--eh, screw that!
> At about Thu, May 27, 2010 at 12:21:29PM -0400,
> Kenneth Brody blabbed on about:
> > Okay everyone, repeat after me:
> > 
> >      The lockfile has nothing to do with record locking.  
> Nothing.  Nada.
> >      Zip.  Zilch.  Zero.
> 
> Ken?  Does the lockfile have anything to do with record 
> locking?  I keep
> hearing, "Yes," and I'm still confused after all these years.
> 
> mark->
> -- 
> Audio panton, cogito singularis,
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>