>Naming findable folders on a network
>
>My users connect to a “main” machine for their shared data. One user runs from the main machine. I want all to have access to a folder that could be on any of the office machines (including the main, the user machines, or others). The folder can be designated by any of the machines, and its location will be stored in an encrypted dbf character field for all to see. The address will be different though for different machines. For the user (John) whose machine holds the folder, it’s at C:\stuff\thefolder. For a different user it’s at \\John\c\stuff\thefolder. For a different user that uses a mapped drive, it could be G:\stuff\thefolder or G:\c\stuff\thefolder.
>
>One application is for keeping a “do-you-exist” file to be found before the system will run (a security thing if the main computer is stolen), and the other is for keeping a folder for each client that batches of invoice pdf’s can be stored in for emailing by one or more of the other users.
>
>I’ve been working on an elaborate system of figuring out from the stored path, if it’s on “my” machine and to use the local naming convention, or on a different machine … and what should be used in that case, but I thought … surely someone else has bumped into this by now. Any thoughts on the best approach of storing and retrieving the folder's location?

I'm not sure what you're trying to achieve but I'll offer a few ideas as a network admin.

Having different names to access folders is likely to be a debugging and maintenance nightmare. It doesn't have to be that way.

I generally recommend setting up a root folder to contain shares e.g. C:\Shares. Individual shares on a per-application basis or otherwise as required are created as subfolders of that e.g.

C:\Shares\App1 --> shared as App1
C:\Shares\App2 --> shared as App2

Keeping the shares out of users' profiles avoids privilege problems.

Set up security groups with appropriate access to the shares. If you have a domain that makes life *much* easier. Assign user accounts to the security groups, never assign share privileges directly to individual accounts. Even if it's just for one user, you'll be thankful later when you have to add others (even temporary/guests).

If you name the shares consistently across all machines, and use UNC (highly recommended) all you have to worry about is the host name e.g.

\\Main\App1
\\Alice\App1
\\Bob\App1

This works 100% fine for a share on your own local computer. For example, if the designated share is \\Main\App1, and you happen to be using host Main, you can access the folder as \\Main\App1. There's no need to dereference that to C:\Shares\App1 - I wouldn't bother.

For those who prefer to use drive letters, you can map a consistent drive letter to your own local share e.g. NET USE G: \\Main\App1 /persistent:y . That's exactly the same command you would run on other hosts. But again, I wouldn't bother - drive maps can become disconnected, it's just another thing that can go wrong, UNCs are more reliable. Some might argue that one thing a mapped drive letter is good for is to move that variable out of the app. The app can be hard-coded to use drive G:, and assume the environment is set up properly prior to running the app so that G: points to the right place. Others would argue that you shouldn't hard code drive paths anyways, so you're setting and storing a drive variable. So, why not just store the UNC \\Host\ShareName ? Also, using G: can be a debugging nightmare - there's no way to know (from within the app) which folder was actually in use if something goes wrong.