fp file locking behavior

[Bob Haussmann]

> > The question remains, why would fP need to issue a lock for writing
> > the index when one is only browsing?
> [...]
> 
> And what would happen if, while the "I'm only browsing" dclerk were
> traversing the index to find a record, a different process were to
> come along and insert/delete a record in the index?

Understood--thank you.  So what state is the index file in when we
have some of the "just looking" processes?  For example, I am able
to COPY the file from a command prompt--does this mean it is
opened non-exclusive for reading?

> 
> Now, the locking is set up such that multiple "just looking" processes
> can access the file simultaneously, but an "I'm modifying the index"
> process has exclusive access during the update.
> 

Given this statement, I'm not sure that I am following.  Since this
behavior gets turned off when PFREADONLY=ON, then what would happen
in the above situation?  The "just looking" processes have the index
file open for reading, and the modifying process opens the index for 
exclusive access?

Interestingly, in the process of testing this, I ran into another
possible locking/file access issue.  I can replicate, but can't
figure out what is going on:

1) create new file, two fields, each 10,*.  Index on each.
2) with PFREADONLY=ON, empty file, try to browse an index:
f:/filepro/test/index.A  Bad file descriptor Last windows error was 5

At first I thought it was because there are no records in the database,
but the same message comes up even if the database is populated with
a few records.  I can run PFREADONLY=ON with other databases
and do not encounter this error.

Bob