Foxpro doesn't open files, Windows does. And there can be a big stack of
filter drivers in play from AV and other things.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
On Tue, 8 Mar 2016, at 05:46 PM, AndyHC wrote:
> As Christof said some years ago: all is not what it seems with Foxpro
> file handling - there is a *lot* of smoke and mirrors!
>
> On 08/03/2016 20:44, Tracy Pearson wrote:
> > I have been tracking down a very random occurrence of a table opened with
> > the Exclusive flag throwing an error.
> >
> > #111 Cannot update the cursor "cursor", since it is read-only.
> >
> > I checked the code, no NOUPDATE flag.
> >
> > I brought up SysInternals Process Monitor and opened, appended a record,
> > and closed a table 10000 times.
> > I had suspected multiple anti-virus and on demand backup tools causing
> > behavior problems.
> > This Windows 7 (virtual machine) has 1 GB RAM, Kaspersky, Bitdefender, and
> > Carbonite installed.
> > No exclusions, and Carbonite is set to specifically backup the data folder
> > on demand.
> >
> > My test actually does a Try/Catch around the USE statement, wrapped in a DO
> > WHILE NOT USED()
> > It seems the tools mentioned are not the direct culprit. Instead when things
> > fail, Windows Explorer was the direct cause. Windows Explorer opens the
> > table Read Only and with Share Read/Write and reads the first 4000 bytes.
> > Then closes the file. Why I don't know, I don't care. I do know it only
> > happens when the Explorer window is open to the folder where the table
> > exist.
> >
> > Lucky for me, the place I open tables is via a class, so a check with
> > ISREADONLY() will prevent this in the future.
> >
> > So what really happens? In Process Monitor I can clearly see I open a table
> > in one session of VFP 9, then in another session of VFP 9 I attempt to open
> > it again. First VFP attempts to open the table Read/Write with Share None.
> > It gets a Sharing Violation. Then VFP attempts to open the table Read Only
> > with Share None. There is that split moment on some machines that VFP is
> > successful.
> >
> > Has anyone else seen this behavior before?
> >
> > Thank you for reading,
> > Tracy
> >
> >
[excessive quoting removed by server]