Hi Rick,
We're in the process of deploying a pair of new stage web servers and I'm investigating the ability to run a VFP dev environment starting from a UNC instead of a local volume. Why, you say? I'm glad you asked that question. Our web environment uses an AWS FSX shared volume for folder/file storage and everything in IIS uses UNCs for pathing. Sadly, it appears that the tilde placeholder used all over the place in the framework/templates results in consecutive backslashes getting STRTRANed out of existence in Response.ExpandScript.
IF LEFT(tcPageName,1) = "~"
tcPageName = STRTRAN(SUBSTR(tcPageName,2),"/","\")
tcPageName = ADDBS(Request.GetApplicationPath()) + tcPageName
tcPageName = STRTRAN(tcPageName,"\\","\")
ENDIF
This all works just fine with a compiled EXE running in COM mode but is less friendly for a local dev setup. Any suggestions on how I might get this to work?
TIA
I think you'll also have an issue with wwProcess.ResolvePath() which uses the same logic.
Can you map the UNC to a drive letter on application startup via API call and then re-root all of the paths to the network drive?
+++ Rick ---
That or some variation could work. I'll give that some thought, much appreciated.
A little research indicates that mapped drives in IIS are not a good thing for several reasons (security & performance). As this is for a dev environment I'll just live with the local volume. But someday in the not too distant future I'm going to have to dive into how to setup & manage multiple servers running in a web farm.
It shouldn't be an issue if you create the mapped drive as part of the application itself and you keep it focused. The mapping would be visible only to the account and session that the IIS Application Pool is running under.
Whether you access the remote via drive or UNC doesn't make a difference for safety - you can get to it either way and it can likely be discovered if you get hacked.
+++ Rick ---
From the wisdom of the pre-ChatGPT internet (typos included):
"Per Microsoft documentation mapped drives are not a viable solution. Sure you can work your way around it and eventually make it work... But its a bad idea because it will cause performance degreation as every call has to be authenticated twice, once by the OS and once by IIS.
Use a UNC path instead."
This is for a local VFP dev environment on this web server that's only used internally. IAC I have other windmills to tilt against and if MS says don't use mapped drives with IIS I'm not going to put more effort into that. As always, I do appreciate you taking the time to offer some suggestions.
Actually my experience is different with this - I've always found that mapped drives are much faster than UNC paths because UNC paths often need to reevaluate the path. Drive maps resolve the path and auth once, and once there it's usually much faster. Not sure if those docs are really old and predate the caching that occurs for the file system.
I know this because I used to map a WAN drive to my Web server. The UNC paths (at least from VFP with data) were painfully slow and just about unusable while the mapped drive was considerably faster. I think this is due because the connection is cached, whereas UNC often ends up reconnecting the entire path. Even for local network connections the performance hit was noticable, but over the WAN it was between unusable and reasonable.
The key is that the map has to be made AFTER IIS has started and in the context of the session that is running.
+++ Rick ---
It was a 2020 post, iirc.
Yeah, VFP with a WAN is a perfect way to have a lot of time on one's hands...