Coding file paths to a server or network share
-
Whatever you do, don't hard code it. I have had to deal with too many old servers over several jobs that can't be upgraded because somebody hardcoded a path rather than putting it into a configuration file or creating an options dialog that allows the user to change it. I would also avoid the mapping.
Driven to the ARMs by x86.
OK, so it took me 4 min to write one post! damn!
It's a shame that stupidity can't be converted into a usable energy source.
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
I agree with the 2 previous posts, and you. Use the path to the server, not mapped drive, but move it to a config file, too. I get scared of hard coded shit like that, but believe me the software here is loaded with it.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
You shouldn't hard-code the path names, however you specify them. Put them in a config file / database table or something that can just be changed without re-deploying. If your environment is one in which the mapped drives are system administered (which, evidently, they're not!) then using mapped drives is a good way of locating the data that provides the information about where on the network stuff resides... e.g. have a system wide map of Z: to some folder in that folder have a config file of some description that holds information about the locations of everything (i.e. if your location information is in a database, it may store the information to log into that database and gain access to the location information, if your location info is in an XML file, then it will have information pointing to that XML file on the network (NOT using a Share) This way, you have a single, central location in which you can make any changes and immediately affect all users. All of your applications local config file then specifies Z:\whatever as the location for the config. now, if the Z: mapped drive changes, you need to just change the mapping centrally (worse case you need to change the mapping on every machine) if the location of any other info changes, you just need to go to the Z: drive, and edit the config to either point to the new location, or find the reference to the location in which the location information is stored (blimey, the English language wasn't made for this sort of explanation!) Your co-workers may argue that if everyone had the same mapped drive, then all would be well, and that if stuff moves around the network you just need to change the map - but that too is dangerous as there may be a requirement to move some, but not all, of the stuff from that mapped drive to another location.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
On rare occasions I've seen software that won't work unless it goes through a mapped drive. That being said; I think Maxx's suggestion is the closest to what I'd go with. Don't forget: Include something to check if the shares is live. And then make sure to specify what happens when the share isn't- does it have a default? Does it halt with a specific error that is easy for the user to take the next step on? Does it flash a warning and proceed? I knew a guy who hard-coded elements like this into the compiled version of code. Guess why...He wanted them to come to him whenever there was a change. He hard-coded a password and rather than go to him they simply didn't bother to change the password.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
-
On rare occasions I've seen software that won't work unless it goes through a mapped drive. That being said; I think Maxx's suggestion is the closest to what I'd go with. Don't forget: Include something to check if the shares is live. And then make sure to specify what happens when the share isn't- does it have a default? Does it halt with a specific error that is easy for the user to take the next step on? Does it flash a warning and proceed? I knew a guy who hard-coded elements like this into the compiled version of code. Guess why...He wanted them to come to him whenever there was a change. He hard-coded a password and rather than go to him they simply didn't bother to change the password.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
hard-coded password computer security at it's finest :laugh:
Steve _________________ I C(++) therefore I am
modified on Wednesday, July 13, 2011 8:33 PM
-
On rare occasions I've seen software that won't work unless it goes through a mapped drive. That being said; I think Maxx's suggestion is the closest to what I'd go with. Don't forget: Include something to check if the shares is live. And then make sure to specify what happens when the share isn't- does it have a default? Does it halt with a specific error that is easy for the user to take the next step on? Does it flash a warning and proceed? I knew a guy who hard-coded elements like this into the compiled version of code. Guess why...He wanted them to come to him whenever there was a change. He hard-coded a password and rather than go to him they simply didn't bother to change the password.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
Yours can be run by the scheduler, theirs - not. (At least, not so easily)
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Whatever you do, don't hard code it. I have had to deal with too many old servers over several jobs that can't be upgraded because somebody hardcoded a path rather than putting it into a configuration file or creating an options dialog that allows the user to change it. I would also avoid the mapping.
Driven to the ARMs by x86.
AspDotNetDev wrote:
Whatever you do, don't hard code it.
Only hard code it if I have to code VBA for older Office Automation apps, which unfortunately, we still have. Other than that it gets thrown into a config file and on very rare occasion it gets put into an .ini file. My question was more how do you approach the file path itself. :) [edit] if I can, I will put it into a database for Office stuff but that doesn't always work out.
----------------------------- Just along for the ride. -----------------------------
-
You are on right path, just want to point out one more thing, which you might be alreay doing here. please put those paths in app.config/web.config/database table so that you can change it without recompiling the app when network location changes. This will also solve the problem if you are not able to convince them to use network path, you can always change the path.
It's a shame that stupidity can't be converted into a usable energy source.
Rutvik Dave wrote:
please put those paths in app.config/web.config/database table
Always...when I can.
----------------------------- Just along for the ride. -----------------------------
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
I'm with you, mapping drives is soooo 90s. X| But still... on my last job I stored paths like your example in a configuration table and all was good... until the DNS went out. As a temporary solution I replaced the server names with the IP addresses. Eventually I wrote a little DNS service that periodically cached the IP addresses of the servers and then my code would replace the server name with the last known IP address on the fly.
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
I personally think that the UNC path (\\server\directory) is the way to go. I'll qualify this statement: If you wrote a service that needed to get files from a shared folder on the network, you must bear in mind that your service can run under different credentials to the logged on user, and as such may not have the same network drive mappings.
-
I personally think that the UNC path (\\server\directory) is the way to go. I'll qualify this statement: If you wrote a service that needed to get files from a shared folder on the network, you must bear in mind that your service can run under different credentials to the logged on user, and as such may not have the same network drive mappings.
In principle the UNC path is the "right" way as it is supposed to be more stable than the mapped drive letter. However, in a corporate setting the reverse may be true. In that case all users will have a number of permanent drive letters mapped on logon. Central IT may change the server names when they move stuff around as they please but the drive letters stay put. I have worked for at least three companies where that is the case. So it ends up with the usual answer: "It depends" :) .
-
In principle the UNC path is the "right" way as it is supposed to be more stable than the mapped drive letter. However, in a corporate setting the reverse may be true. In that case all users will have a number of permanent drive letters mapped on logon. Central IT may change the server names when they move stuff around as they please but the drive letters stay put. I have worked for at least three companies where that is the case. So it ends up with the usual answer: "It depends" :) .
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
Something to watch out for, depending on the client using the app - if the program is actually running on the machine that the UNC path is referencing, the local resource path cannot be accessed using UNC naming if the machine is set to use simple file sharing method to set file sharing permissions, at least not on XP. Took me a while to figure that one out.
OldDude
-
Something to watch out for, depending on the client using the app - if the program is actually running on the machine that the UNC path is referencing, the local resource path cannot be accessed using UNC naming if the machine is set to use simple file sharing method to set file sharing permissions, at least not on XP. Took me a while to figure that one out.
OldDude
Thanks for the tip. I did not know this.
----------------------------- Just along for the ride. -----------------------------
-
We do a lot of in-house software and utilities that access network shares and servers. I usually code the path like so:
\\MYSERVER001\SomeCrazyDirectory
Some of my colleagues code the path of the mapped drive (on their workstation). Problem is, if you put the app on someone's workstation/computer it won't work unless they have the exact same mapping, which doesn't always work out. Am I looking at this the wrong way?
----------------------------- Just along for the ride. -----------------------------
Always use a \\DNS_SERVER_NAME\directory\path. Never use a \\PhysicalServerName\It\will\be\replaced. Get your local DNS person to code the \\DNS_SERVER_NAME to \\PhysicalServerName mapping, so you can update everything at the one point. (I've had to have a local DNS entry that has to map a \\previous-company-name\hard-server-name to the latest virtual server!) Use the
PathCopy4
utility (use your favourite search engine!). It is wonderful for getting proper paths. It's also great for folks pasting proper paths into emails (wrap with <....> angle brackets for blanks in path \ file names in plain text emails)
-
Always use a \\DNS_SERVER_NAME\directory\path. Never use a \\PhysicalServerName\It\will\be\replaced. Get your local DNS person to code the \\DNS_SERVER_NAME to \\PhysicalServerName mapping, so you can update everything at the one point. (I've had to have a local DNS entry that has to map a \\previous-company-name\hard-server-name to the latest virtual server!) Use the
PathCopy4
utility (use your favourite search engine!). It is wonderful for getting proper paths. It's also great for folks pasting proper paths into emails (wrap with <....> angle brackets for blanks in path \ file names in plain text emails)
Thanks for the info Philip.
----------------------------- Just along for the ride. -----------------------------
-
Slacker007 wrote:
Am I looking at this the wrong way?
i vote : No
I also vote NO. However, there is the case where you MOVE all of the shared data to another machine. If you used mapped drives, then all the user needs to do is remap. But I always lean towards using UNC.
-
AspDotNetDev wrote:
Whatever you do, don't hard code it.
Only hard code it if I have to code VBA for older Office Automation apps, which unfortunately, we still have. Other than that it gets thrown into a config file and on very rare occasion it gets put into an .ini file. My question was more how do you approach the file path itself. :) [edit] if I can, I will put it into a database for Office stuff but that doesn't always work out.
----------------------------- Just along for the ride. -----------------------------
Once it's in an external configuration file, it no longer matters whether it's the mapped Q: drive or \\serverQ\share1 that's referenced because it can be changed without changing the software.