Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Current state of opportunistic locking, SMB2, SMB3, & VFP?

Status
Not open for further replies.

jongoad

Programmer
Oct 12, 2007
11
US
Can anyone confirm or deny if Microsoft ever fixed the problem with opportunistic locking/SMB2/SMB3 that made it necessary to apply a registry hack to the server and/or workstations to prevent table and index corruption with VFP and other file-server databases? In other words, are those of you who support multi-user VFP apps still finding it necessary to apply those registry hacks, or should that no longer be necessary?

Thanks,

Jon
 
Do you know what version VFP these were written in?
It may be if you "upgrade" to the last version of VFP and apply all the patches this will work. I don't use opportunistic table/file locking in almost any cases, so I've never encountered this issue.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Scott, this is not about VFPs optimistic locking, this is about SMB2 Windows file protocol opportunistic locking.

Bye, Olaf.
 
The app in question is written in VFP 9 SP2, but this problem isn't specific to VFP. It affects any ISAM-style file-server database where multiple users are updating the same shared files at the same time (in VFP's case, DBF and CDX files). It's technically a Windows issue rather than a VFP issue, but VFP databases happen to be affected by it.

There used to be a number of articles on the web (including this one: that told exactly which registry keys to tweak in order to tell Windows to fall back to using the older SMB1 protocol, but most of them seem to have been edited to remove that info or have disappeared altogether. I was wondering if they had been edited/removed because Microsoft had actually fixed the issue, so the registry tweaks were no longer necessary. But I'm having a hard time finding confirmation of that.
 
Ah, I see I was thinking optimistic (now I see the word opportunistic) being different.
This "hack" I'm not aware of.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
I was wondering if they had been edited/removed because Microsoft had actually fixed the issue, so the registry tweaks were no longer necessary. But I'm having a hard time finding confirmation of that.

I've no special information about this, but I doubt that they would have removed the information simply because they have fixed the problem. There will always be people using old versions of Windows who will need the information. In any case, the information is still present on the Microsoft support site. See, for example,
But I think it's more likely that they haven't fixed it. In fact, I'm not even sure the word "fix" is appropriate here. After all, while it might be sensible to switch off Oplocks by default in a VFP environment, there's are still good reasons to maintain it in a client-server database setup. It's not as if there is any kind of bug involved.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
It would appear that Microsoft did issue a hotfix, so I think it's safe to say they acknowledged it as being a bug:



What I'm trying to find out is if the supposed fix actually worked for people who have since put it into place, or if we should keep disabling SMB2/SMB3 for our multi-user VFP apps that run over a LAN.
 
This fix is old and still complaints about the usual issues come into this and other forums, and this Hotfix has long become part of usual Windows. So the fix, whille it may have fixed the problem MS Access had with it, is not solving it for VFP.

The point is, now - at least in win10 - you can't turn off smb2, as smb1 really is insecure (malware attacks used it).

The best you can do is minimize the timeout of such opportunistic locks:
Code:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

Bye, Olaf.
 
I think that op locks are only really a problem on the server end these days, you don't need to knobble your workstations, just the server.

This article helps with 2012, which is still pretty common.

I don't know how to do it in Server 2016... yet

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
It was always easiest to only cope with the server, but as a developer, you could mainly address the clients easier via your application, and wouldn't need the support of the administration. Nowadays it's impossible if SMB1 isn't available anymore on Win10 and Server 2016, as I understand the latest situation.

Bye, Olaf.
 
Wow, so according to that link, "...the old way of disabling it within the registry no longer works..." That's definitely good information to know.
 
Well, using Set-smbclientconfiguration -useopportunisticlocking $false or $true changes

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\UseOpportunisticLocking

That cmdlet might do more than merely change the reg key, but as far as I remember a server restart is necessary to put the regkeys into action and if you don't do so, you might get the impression the registry has no influence.

Bye, Olaf.
 
Good point, Olaf. I probably should have said "That's definitely good information to know--assuming it's correct".
 
Another thing is obvious: I think it can be easier to execute some cmdlets, though applying a reg file also is quite easy, once you have the elevation to do so, which is necessary for both ways.

Bye, Olaf.
 
We've got a client who just set up a new Windows Server 2012 R2, applied all Windows updates, etc. and began doing some testing with several users working in the application. Workstations are all running Windows 10. We told them to not apply any changes for opportunistic locking. Right away, they began to receive messages that DBF and CDX files were being corrupted. So, assuming the so-called hotfix is included in standard Windows updates (from what I've read, it's supposed to be), it would appear that it doesn't fix the problem for a multi-user VFP application. So now we're recommending that they apply the op-locks tweak to the server.
 
Thanks for sharing that info. It confirms what I thought, but it makes it more than just an assumption.

Now it would be a time to act for Microsoft, but I fear they won't do any further fixes, though it surely can affect other software than Foxpro.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top