Problem with lockfiles, and file ownership(?)

[Kenneth Brody]

On 2/7/2016 3:49 PM, Del via Filepro-list wrote:
[...]
> To make a long story short, I began to run into lockfile and file
> ownership problems.

If the ownership on the lockfile is wrong, then you either have wrong 
permissions on filePro binaries (run "setperms"), or you have something 
outside of filePro creating or chown'ing the lockfile.

> That is, the whole process would run a couple of
> times without any problem, very fast, doing a bunch of input and record
> updates that would take a human operator way, way more time to input
> manually – and then, on the third or fourth try, after restoring the very
> same data files, it would blow up with an error message of “lockfile not
> found”.

What's the actual error message wording?

>  {This is the message I got most frequently, but I also sometimes
> got a Windows message 32, saying a file was currently in use by another
> process, or something to that effect, which was obviously untrue since no
> other processes were running.)

You're on Windows?  Then how do you get "ownership problems"?

Any chance something outside of filePro is locking the lockfile for some 
reason?  Every place in filePro that touches the lockfile always protects 
the access by locking it.  And if the lock fails because someone else has it 
locked, filePro waits.

> So I took a look at the lockfile, and it
> was there ok, so why didn’t filepro find it?

What do you mean by "didn't find it"?

>  After a lot of messing
> around, I realized that this message really meant that the lockfile was
> still owned by by an earlier iteration of the same process and for that
> reason was not available later when the process again issued a lookup or
> update or whatever it was that prompted the error.

What do you mean by "owned by an earlier iteration"?

[...]
> So I got desperate and started deleting lockfiles, just to see if that
> would solve the problem, and I put in commands to execute  “dprodir
> (filename) –l” in a lot of places where it was blowing up, and that
> seemed to reduce the frequency of the problem, but it still happened on
> the third or forth run through the same process with identical data.

Simply removing the lockfile is asking for problems down the road.  The 
lockfile exists for a reason.

> After seeing it work so many times with identical (and even sometimes
> different) data, I decided that this was not an error in my code, but had
> to be some kind of dclerk5.0.14DN9/Windows 7 PRO operating system
> problem, maybe a timing problem of some sort, where files, like a
> lockfile, were not being released by Windows to keep up with the very
> fast running process, thus causing subsequent attempts to reuse the same
> file to fail.

As I've noted before, if there is a "timing issue" like that, then there is 
a *major* *bug* in your network or O/S software.

[...]
> If you have read all the way through this admittedly long email, thank
> you for your patience.

Can you please give some more specifics, such as the actual error message 
you get (I do not believe filePro would ever say "lockfile not found"), as 
well as clarifying things like your meaning of "owned by an earlier 
iteration", as mentioned above?

-- 
Kenneth Brody