VFP File Lock Issues with Windows Server

[rbeitler]

About 2.5 weeks ago we starting seeing issues with file locks. Typically getting error 1705 "File access is denied". We have an internal VFP app that runs in 3 locations, each with its own server, and started seeing this at all locations. For the most part, this is code that has been running fine for years with no issues.
The code in particular where these issues happen do have some things in common:

• If a dbf is open shared, but then needs to be opened exclusive, the error will happen even in no one else is using the dbf (usually temporary tables)
• Calling FOPEN on a log file during a loop where is is repeatedly doing FOPEN and FCLOSE on the same file.

So in both cases it seems to be tripping on itself so to speak.
The files are accessed over the network via Windows Server. We tried to disable oplocks using the set-smbshare and setting the LeasingMode to none. Every time we reboot the server everything works for a day or two. Then issues start to come back. We tried disabling antivirus, no joy.

We are in the process of refactoring our code to avoid this situation, like open exclusive the first time, keep log files open, etc.

Has anyone else who still uses VFP seen any similar behavior?

 

[mmerlinn]

So in both cases it seems to be tripping on itself so to speak.

Tripping on itself? That suggests timing issues.

Try inserting some timing delays in your code to see if that solves the problem. If it does, then you will have a better idea how to attack the problem.

 

[Joe Crescenzi]

So in both cases it seems to be tripping on itself so to speak.
The files are accessed over the network via Windows Server. We tried to disable oplocks using the set-smbshare and setting the LeasingMode to none. Every time we reboot the

Years ago we had terms for this scenario, "Deadlock" and "The Deadly Embrace", which was a situation where you have two resources competing for access. In some cases one process is waiting for another process to complete before moving on, yet the second process could, in fact, be waiting for the first process to complete, hence the deadlock.

To avoid a Deadlock, you should consider trapping those situations so they are not locking something while waiting to get access to something else that is locked because it's possible that the other task is doing likewise waiting for whatever locks you already have.

@mmerlinn is correct, timing plays a big role. You should try to limit the amount of time you need exclusive use of anything, whether it's a record or a file. Personally, I only open DBFs in shared mode unless I am reindexing or altering the structure, but if you have no workaround, you need to keep those exclusive uses as short as possible and release the exclusive use as quickly as possible.

Back in the 80s, before true shared networking was possible what people did was work in batches. You wrote your information to a temp file, which you had exclusive use of, then had a way to combine your temp file with the live master later.

You can use the same idea with the log file. If an FOPEN is trying to write to a log the entire time, see if you can save it to a temp file, which is always exclusive and then append the resulting file to the complete log at the end, so instead of keeping the full log open the whole time, it only needs to open it for a fraction of a second while your temporary log is appended.

HOWEVER, if the system has worked all these years, and you've never needed any of these techniques before, there's still a chance it's from a hanging lock from an aborted session. Simply stated. if there are no other people using a file, it should never block you from opening it exclusively.

One scenario I've seen is that a user may have a file open, then their system goes into suspend or hibernate mode, or even reboots or shuts down unexpectedly, and somehow the server doesn't realize they are no longer there. Another scenario I've seen is where a client had a web portal that allowed people to view some of the data online. The web server typically keeps those files open long after the web session closes. Lastly, I've seen backup systems that interfere with file access.

If you have a traditional Windows shared folder, you should be able to see what files are open at any given time and by which account(s) and even know if there are any record locks in use. If nothing else, once you identify who the system thinks is using the file you can determine whether it's even somebody who is no longer logged in.

 

[Chris Miller]

Are you using views in a shared dbc, too? You did explicitly tal about dbfs, I know, and log files, that are neither views. I mention it because for views it's a known issue, that in the moment a view is opened, an error 1705 can happen, and the solution to that is to let every user have thier own copy of a view dbc and only share a dbc with dbfs.

If a dbf is open shared, but then needs to be opened exclusive, the error will happen even in no one else is using the dbf (usually temporary tables)

Why use temp tables instead of cursor? I guess there is a reason. But then are they created locally or in the share? Everything you create for a single user, that's used in a report, for example, should not even get a remote chance of causing trouble with other users creating the same temp file in the same place. There's TEMP for temp files.

Is Terminal server involved? MS does give user sessions each a separate local TEMP folder on the terminal server, which avoids double usage of the same temp file, of course, but if you set temp files in your application to something else than the OS this could cause double usage of the same file again on different user sessions running in the same terminal server. I therefore strongly recommend using the Windows TEMP folder always, even if you're not using terminal server right now, it makes the transition a lot easier, if it would ever be considered.

If you have a dbf for which the lock problem occurs most often, it pays to use procmon for file monitoring to see what has file handles on files and see what's happening on the dbfs, whether it's really the same client tripping over its own usage.

Both local AV and server side AV could potentially act on share files, the server AV because it's examining all server side files an also shares, local AV could because a process is opening files of a server share. So AV still might being the issue.

 

[Chris Miller]

By the way, doing some experimenting:

Using one VFP IDE (process) with one datasession:
Using a dbf shared or exclusive in one workarea, then trying
USE thesame.dbf EXCLUSIVE leads to error 3, not 1705
Which also means you can even use the same dbf twice in the same datasession with another alias name,i.e.
USE thesame.dbf EXCLUSIVE ALIAS othername AGAIN IN 0 works.


Using one VFP IDE (process) with two datasessions:
Trying USE thesame.dbf EXCLUSIVE also triggers error 3, not 1705.

Using a second VFP IDE (process):
Trying USE thesame.dbf EXCLUSIVE triggers error 1705.

It's exhaustive enough for me, but you might consider further cases, like exclusive access with other alias name and AGAIN clause in a second datasession (but still the same process). I'm also currently only using a notebook not joined to a network. So actual network challenges are untested, actual multi users, too.

I'm quite sure, though, that the same user could only trip on its own usage with error 1705 in a separate process, like the same application started twice. If your application logic doesn't consider that case, it's not really the same user for the file system, if it's a second process, even when that runs on the same Windows user account on the same client PC.

Otherwise it should be a second user or process access to the same file, also possibly by AV running client or server side or both. As you say this is happening on multiple locations each with their own server, it's pointing towards a windows update causing that, but I'm not aware of a new general locks problem in networking than the over a decade old oplocks problem. A new user starting the application multiple times to do things in parallel, for example, would also only be a new "pattern" on one location, not on all three locations at the same time, very unlikely, unless a new feature is making that a logical solution to users. The least probable, but still also a scenario I wouldn't encounter for the first time is usage of an old feature for the first time, even though it's already old. That means, a feature that never worked, but was just also never used. Also quite unlikely in three locations, so perhaps rather a newer feature, have you introduced something in the time the problem began to occur?