Coding file paths to a server or network share
-
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. -----------------------------
I could be blowing smoke, but isn't there a way to programmaticly get the path from the server that the files reside on? As in you have to code go to the location, then return the virtual path in regards to the machine running the code at the time? Dang it now I have to go look.
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning. Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
-
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. -----------------------------
Slacker007 wrote:
Am I looking at this the wrong way?
i vote : No
-
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. -----------------------------
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.
-
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 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.
-
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" :) .