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. -----------------------------
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.
-
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. -----------------------------
Here is one observation from my experience. If any of your users have a slow network connection (read psuedo-high-speed satellite internet) than the mapped drive solution poses another problem. Every time they un-minimize *any* Windows Explorer window, it will have to re-resolve the network connection to that mapped network drive and will cause a delay (sometimes serious delay) restoring the file system view. For this reason, I always go with UNC paths. Dave Smith
-
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 also agree with stick it in the config. This will make you give it a symbolic name vs. just a path name. This works for targeting a file location. If you are passing (sourcing) the path to some service that lives on a different computer, then you might do what we do: Given C:\TopDir\dir1\dir2\dir3\file.txt We assume that TopDir is probably a share, but then we confirm this by verifying the existence of the this file: \\ComputerName\TopDir\dir1\dir2\dir3\file.txt If this exists, then the assumption is probably true. (You could also verify that the size and timestamps match) It is safe to pass \\ComputerName\TopDir\dir1\dir2\dir3\file.txt to another system.
-
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've just done what I think you are looking for. Here is VB.net solution: Private mappedDrives As New SortedList(10) Private Sub MapDrives() Dim Drives() As DriveInfo = DriveInfo.GetDrives() Dim letter As String Dim uncpath As String For Each Drive As DriveInfo In Drives If Drive.DriveType = DriveType.Fixed Then letter = Drive.Name.Substring(0, 1) uncpath = "\\" & hostName & "\" & letter & "$" mappedDrives.Add(letter, uncpath) ElseIf Drive.DriveType = DriveType.Network Then letter = Drive.Name.Substring(0, 1) uncpath = GetUNCPath(Drive.Name.Substring(0, 2)) mappedDrives.Add(letter, uncpath) End If Next End Sub If DataFileOpenFileDialog.ShowDialog() = Windows.Forms.DialogResult.OK Then Dim filepath As String = DataFileOpenFileDialog.FileName Dim uncName As String = filepath If Not filepath.StartsWith("\\") Then Dim driveLetter As String = filepath.Substring(0, 1) uncName = CStr(mappedDrives.Item(driveLetter)) uncName &= filepath.Substring(2) End If End If Cheers, Phil
-
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. -----------------------------
Don't use a mapped drive. There always seem to be conflicts on some system or another sooner or later. If a config file isn't viable, even a DIY one, then use the full UNC path like you do. Worst case, if the server fails and isn't replaced by one with the same name, you can always remap it on the customer's computer via System32\drivers\etc\lmhosts. Not pretty, nor convenient, but works.
patbob
-
I've just done what I think you are looking for. Here is VB.net solution: Private mappedDrives As New SortedList(10) Private Sub MapDrives() Dim Drives() As DriveInfo = DriveInfo.GetDrives() Dim letter As String Dim uncpath As String For Each Drive As DriveInfo In Drives If Drive.DriveType = DriveType.Fixed Then letter = Drive.Name.Substring(0, 1) uncpath = "\\" & hostName & "\" & letter & "$" mappedDrives.Add(letter, uncpath) ElseIf Drive.DriveType = DriveType.Network Then letter = Drive.Name.Substring(0, 1) uncpath = GetUNCPath(Drive.Name.Substring(0, 2)) mappedDrives.Add(letter, uncpath) End If Next End Sub If DataFileOpenFileDialog.ShowDialog() = Windows.Forms.DialogResult.OK Then Dim filepath As String = DataFileOpenFileDialog.FileName Dim uncName As String = filepath If Not filepath.StartsWith("\\") Then Dim driveLetter As String = filepath.Substring(0, 1) uncName = CStr(mappedDrives.Item(driveLetter)) uncName &= filepath.Substring(2) End If End If Cheers, Phil
I appreciate the code snippet but I was only wanting to get a point of view on the subject. You know, you may want to post this as a Tip/Trick if you think it is good and other people could use it.
----------------------------- 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. -----------------------------
You could use DNS aliases for the network shares. This way, you can use the DNS name however you wish. If the server or share ever changes you just update the DNS entry and all the apps don't know the difference. This also allows you to create DNS entries with names based on the roles or services not the server it's on at the time. Here's some info on it: http://serverfault.com/questions/23823/how-to-configure-windows-machine-to-allow-file-sharing-with-dns-alias[^] Or you can Google dns-alias 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. -----------------------------
I ALWAYS use UNC paths and stick them into a config file. Drive letters are asking for trouble further down the track. Hardcoding something that is effectively a parameter into an app likewise. If your neighbours don't listen to the Ramones, turn it up extra loud so they can.
-
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.