Oplock when installed on local pc but data is on network server?

[Vince Wen]

I've read all I can on this forum re: oplock with VFP9 application on a network server.

My question is a little different.

What about if the application is installed on a local pc, but the data is on a network server? Would this setup still have the same oplock issue?

Logically, I think it would, but I wanted to double-check this.

ps. I am a newb. So apologies in advance if this question is basic.

-vince

 

[Chris Miller]

The per share command is

Set-SmbShare -Name "Sharename" -LeasingMode None

If you can do

set-SmbServerConfiguration -EnableLeasing $False

you can also do that, but usually you won't have permission to do either. That's the point, so when you rely on admins defining the shares, you also depend on them making the leasing setting, don't you? And they will generally be much happier with only effecting a share than the whole server.

I wonder how you don't know the share names. Do you they only tell you the mapped drive letter for a share? In the interest of not polluting clients drive letters in my case they actually were very happy to not map shares to drive letters and let me use UNC path notation with the share name. \\servername\sharename\...

Well, besides that, when a share is configured that way you also don't need to know the share name, if that's what the admins of your customer is happier with. But in a larger company I don't think they will ever be happy to create a drive letter mapping for every application needing a share for it's centralized files, like data is.

 

[tomk3]

We use MS-SQL for years but anyway, an interesting thread

I remember that using a Linux fileserver or a NAS also solves the OPlock problems

 

[ManniB]

Chris, usually we don't get involved much in the installation of the application or setting up the shares or mapped drives. We leave that to the user himself or his administrator. We only tell them to create a shortcut on the workstations pointing to the exe on the server or pc where the data is stored. The rest is up to the user.

Because the option to disable leasing per share was introduced by Microsoft only later on, we so far used the powershell command during installation of the VFP app on the server

set-SmbServerConfiguration -EnableLeasing $False

to disable leasing for all shares. Because our customers are small businesses and our application is the main application used on the network there haven't been conflicts so far.

If we now change this approach to

Set-SmbShare -Name "Sharename" -LeasingMode None

which would be the prefered way, there would be an additional task to be done manually by the administrator. He would also have to roll back the

set-SmbServerConfiguration -EnableLeasing $False

We are afraid, if they get this setting wrong, it can lead to a serious data loss.

Alternatively, in the installation routine we could roll back this setting, then skip through all shares on the server and disable leasing for all shares that include the data folder of our application. This might be the best option as it doesn't change shares that don't invovle our application. What do you think?

We could also add a check, that if the powershell commands fail, a message is displayed indicating that the required permissions are missing, and that the failed command should be executed on the server.

Thanks,
Manni

 

[Chris Miller]

Manni, in your situation I wouldn't change anything in existing setups, but it can easily be changed for the future, can't it? If an admin creates a share, it's a minimally added effort to set that share's leasing mode.

Whether anything else used networked would benefit much from oplocks would be your only motivation to put work into changing the leasing mode behavior from the whole server to only the share. It's simple enough, if only one share serves DBFs, isn't it? Two commands, first set the share's leasing mode to none and then reanable leasing for the whole server so only one share is not doing leasing mode and thus no leasing-oplocks.

I don't think you need to be afraid that set-SmbServerConfiguration -EnableLeasing $True would go through all shares having -LeasingMode None and reenables them. Even if, then also do the Set-SmbShare -Name "Sharename" -LeasingMode None once more. Three lines of code to be done.

 

[ManniB]

Thank you, Chris.

I'll think of new a way during installation to try to make the setting

set-SmbServerConfiguration -EnableLeasing $False

only under the condition that leasing hasn't been disabled for any of the existing shares using

Set-SmbShare -Name "Sharename" -LeasingMode None

This way, as soon as the administrator has disabled leasing for a specific share, I know, he has taken care of these settings and I can discard the global setting.

So the VFP app continues make the global setting for users who haven't followed the instruction to disable leasing of the relevant share but respects the settings of admins who follow the instruction and in that case doesn't mess with the global settings.

Regard,
Manni

 

[Chris Miller]

While that works, Manni, I ask myself how a setup that's usually applied to a client pc installing the application and not the data, would do any of the leasing mode settings. They both are done on the server. So the leasing mode conguration always has to be done on the server side and would be part of a server installation, if you have such a setup at all. The server side setup is usually a one off job for a customer that's not even needing upgrades with application upgrades and only plays a role once more, if there is a server migration.

If your setup is a terminal server setup, the leasing mode makes no difference if the applilcation uses a local drive for the data, when a secondary server is having a file share, the same thing applies again, the leasing setting is then separate from the application setup as it's not on the same computer, again.

 

[ManniB]

Chris, we don't use terminal servers. The installation of updates always has to be done on the "server". The "server" is the pc where the DBF files and the exe file of the VFP app are located. During this installation the smb server settings can be changed.

The other workstations ("clients") only access the exe file in the application folder on the server. There is a smaller installation done on the clients which makes registry changes etc. but doesn't change the data on the server. During the installation on the clients I could also change client smb settings, but I think these are obsolete when the settings are already done on the server.

Thanks,
Manni

 

[Chris Miller]

So effectively you do a server setup and a minor client setup, okay. It doesn't matter if a workstation/client Windows OS version is used as a server or not, the leasing configuration is done on a server.

You see so used to it that you don't even realize what you do is what most don't. If you create a setup of an application that's usually what you install on every client, i.e. no central exe, every client PC has their own EXE.

I understand you don't let users run a remote desktop session where the EXE is installed, that's used by the user working on that workstation, but others get a link to that exe starting it and VFP runtime DLLs, likely. It always has bee an unideal setup before even oplocks existed.

 

[ManniB]

Yes, the client PCs start the exe from the server. I know this configuration is not ideal, but has been around for a long time and Doug Hennig also mentions it in one of his papers. I'd like to change that soon, so the shortcuts on the clients will point to a launcher exe on the server instead of the VFP exe on the server. The launcher.exe should then copy the application exe to a local folder and run it from there to avoid the network traffic and loss of speed that come with running the exe from the server.

 

[Chris Miller]

I guess you mean Doug Hennig shows how xcopy deployment works, maybe even in more than one paper or article, but that's not the same as having a link to a central exe.

It's true you can minimize the work on each client, especially if you don't need parts of the runtime like the foxhhelpN.exe or ActiveX controls needing to be registered for clients. But that's done by a batch copy script.

Alone the fact that each time you start an EXE from a network location through a link you load at least part of it and throughout usage of all features you load the whole exe and nothing of that remains at a client is making me think why people choose that, just because it keeps one exe at one place. You still have a hard time swapping it out with a newer version if only one user runs it.

If you argue the copy script will copy the whole exe every time than you don't understand how you can limit coping to only newer files. So the usual copy run will access every file in the central share once to find out it's the same you already have, but that's all access to the files, usually and the start is as good as a local installation.

Small companies will not have/use sotware configuartion management to push software to clients, that would be the enterprise solution to that software roll out management.

Anyway, that's all abot how to manage installation and upgrading of software. As we figured out what you actually do is a server setup, whether that should have an additional client setup or just a n xcopy/robocopy batch file clients link to, you install the DBFs and can easily choose whether your setup turns of leasing for the whole server or you sete this for the share your setup must also create where you store the central database of your application, it's an integratable step, isn't it? Or do you only let the setup create the directory of dbfs (and maybe dbc)? It's not impossible to make that directory a share, even specify its name, use UNC paths in the application without mapping a drive and turning leasing off only for that share. So very many things you already wondered about how to manage them are in your very own hands. I wonder why you don't realize this.

 

[ManniB]

The setup on the server creates a folder where the application exe, DBF-files, DLLs etc. are stored. Everything else, how shares are created is left to the user, it's not part of the installer. And most of these shares have of course been created a long time ago and are running. As a developer I don't know the name of the shares or whether UNC or mapped drives are used-it's not under my control. Thus, advising the users to disable leasing for the share used is an extra, manual step. That's why introducing this setting globally on the server during installation was the easiest way to make sure oplocks and caching is not hurting the application.

Rearding Doug Hennig mentioning the server installation: No, if I remeber correctly it was a paper talking about InnoSetup and it was talked about creating a separate installer for the server and the clients. It also mentioned the client pc accessing the single exe on the server. It had nothing to do with batch files.

I know this kind of server installation has it's disadvantages but it's one of the easiest setups and therefore was used by many developers for a long time, maybe not by the experts like you It was also proven that running the exe locally speeds up the application copmared to running the exe from the sever, there wouldn't be a need to proof this when nobody was using it.

Thanks,
Manni

 

[Chris Miller]

there wouldn't be a need to proof this when nobody was using it.

That's right but at the same tie wrong on another level. I think the proof was made to motivate people to not go this route anymore.

I looked a bit into what Doug Hennig recommends and says he uses himself.
In an article that highlighted how to determine system paths, for example to determine where to store data at https://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.html, there's a lot of comments and in the last one his answer is

Doug Hennig:
I'm not using CommonAppData in a LAN situation but rather a shared folder on a server.

A comment in his code is stating:

"CommonAppData": application data for all users

But that's only true for a case of multiple users using a single computer, it's not meant for the case of a multiuser environment with multiple clients.

I know a lot of people use it, but I also always see the recommendations to not do this, when someone posts he's doing that. Be it CommonAppData or any other directory made known by an ini file that's always in the EXE directory. Well, and if you make a lionk to that exe, you do put the knowlegde about either the share name or the mapped drive letter into creating that link, it has to point to the exe on that share, doesn't it?

You can use net share to create a share, it's not complicated, and I guess it takes 3 minutes to find the correspding powershell comandlet to also do that. If instead you tell tpeople to install into a share they already have, that's making your setup depend on requirements, not a good move to have everything under your control. You seem to have some wrong ideas about why not to take this into your own hands, shares don't have a cost, you can create a share just for your own application and make it's data or also the exe visible to other clients that way, nothing against that, if you then go for the right way of usage of that, i.e. not using that exe from that place directly.

You also don't need a client side batchfile, that can be within the central share, too, so all any client needs is the link to a start batch file. Well, as long as you don't need to roll out anything else like registry entries, ActiveX controls, etc. to all clients. But vfp9r.dll can be copied and will then be used by each single client/user once only, too. No need for any registration. And that's also all known for decades.

 

[ManniB]

Chris, I haven't invented that approach and I'm not justifying it, but I have to work with it now as it is and potentially change it in the future. I was bringing up that example to underline I'm not the only one using it and you comfirmed you know a lot of people who work that way, too. I feel like you always take what I say the wrong way.

You were giving me some good ideas about the ini file and batch scripts being on the server also, which I might get back to once I implement a better solution.

Thanks,
Manni

PS: I found where Doug Hennig was talking about this:

https://doughennig.com/Papers/Pub/IntegratingRSSandVFP.pdf

Running the application on a workstation
Often applications are installed on a file server and run on workstations from the server
folder. With a simple VFP application, it’s possible to do that without installing anything on
the workstation. For example, the main form in the sample MyApp.EXE that comes with the
file accompanying this document works just fine in that case. However, there are several
gotchas for this type of setup:...

 

[Chris Miller]

you comfirmed you know a lot of people who work that way, too.

Until they learned otherwise. And it always surprises me to still find someone in this old outdated, easy to fix way. Your insight that the batch file can be on the server too is "insane". Why do you get that an EXE can run from a server and don't think about how easy it is to also establish a batch file that does the "rollout" to all clients. Provided you use an application directory not in c:\program files(x86) it's easy to do and still also protect against viruses.

It's still not the best, but much better than an EXE kept on a server share or a share on another workgroup pc.

 

[ManniB]

Why do you feel the need to insult me?

 

[Tore Bleken]

"Why do you feel the need to insult me?" Because someone always knows best, and always want to have the last word. That's the main reason why I have stopped posting on this forum.
That, and the huge number of trolls here. Forgive me, I mean people who hide behind a stupid alias instead of using their real name. In most other forums you must use your name, and that's a very good thing.

 

[Chris Miller]

I don't insult, I just post observations, don't let a solution watered down and keep my standpoint.

If someone realizes he could have done better and ge's a bad feeling from that insight and connects this bad feeling coming from me is an insult, I don't even feel the need to ask for a pardon, sorry.

 

[Chris Miller]

Just on topic: I don't even find the quoted text in the IntegratingRSSandVFP.pdf.
but it helped to find https://doughennig.com/papers/Pub/Deploying.pdf.

 

[Chris Miller]

Okay, I looked into this article deep enough to understand his idea. It's very involved in many things and indeed encourages to make a setup on a file server and a separate workstation setup only for runtimes and ActiveX controls to work, but also points out regfree mechanisms that can reduce this. He copied one error that alrady the fox wikis made popular, that the vfp9r.dll has to be registered. It is sufficient if it is in the same folder as an EXE. But anyway, that's just a detila error.

He's really suggesting to use a central exe installed on a server or a central workstation and other client workstations use that via a shortcut link only, provided the client workstations have the workstation setup run for them, for example to make CHM work with a CHM file on a network.

Taking aside the solution I propose is simpler when putting all the effort in implementing an update mechnism for the installed EXE, you could also use that to install that complete setup on every client workstation and they stay in sync from a source that could even be hosted in the internet.

If multiple users use the same EXE they not only could suffer from less performance due to the remote EXE location, you can also get network errors. For example, Error 1000 (Internal consistency error) that is hard to relate to coming from that. Error 1793 (The network request is not supported), which made the developer look into problems with DBF access, not the EXE. And I may have forgotten more.