What paths are guaranteed to exist on Windows Server 2008 R2?

What paths are guaranteed to exist on a Windows Server 2008 R2 instance? A client is requiring that some instructions specify exact paths in all cases. (The person executing said instructions is not supposed to have to decide on any path themselves, even when the path makes absolutely no difference.) So I need to know what paths I can rely on to be there. It's fine with me if they involve environment variables, but they need to be variables guaranteed to hold an existing path. (That is, no modification to a path that doesn't exist possible.)

Or are there no guaranteed paths?

windows-server-2008-r2

jpmc26

Posted 2012-09-05T23:05:05.387

Reputation: 393

To be honest, I'm hoping the answer is that there are none. Then I can respond to this by telling them they have to guarantee me some paths exist before I can make the change. – jpmc26 – 2012-09-05T23:06:43.713

It is better to use environmental variables for paths rather than hard coded paths as some of the paths may change slightly, but the variable won't: http://www.technipages.com/list-of-windows-environment-variables.html

– MaQleod – 2012-09-05T23:10:22.353

Fair enough, but are they guaranteed to represent existing locations? – jpmc26 – 2012-09-05T23:15:09.460

That is the point of environmental variables - a common variable name that holds specific details to the current system configuration. For instance, %HOMEPATH% will always point to the currently logged in user's home directory, this will always be a valid path. Better yet, that specific option will always be writable to the currently logged in user, so you won't have to worry about permissions getting in the way either (unlike if you chose %HOMEDRIVE%, where Group Policy may prevent a user from writing to). – MaQleod – 2012-09-05T23:21:52.150

Yes, many of the various environmental variables that point to folders must exist in order for Windows to operate. – afrazier – 2012-09-05T23:23:02.040

If someone would post that below and name one or two of them, I will accept it as the answer. – jpmc26 – 2012-09-05T23:24:15.017

Answers

You can use environmental variables. These are variables that the system uses and so they are required to be valid paths. They are also ones that will work across various Windows platforms, so even if the standard hard coded paths change, the path loaded into the variable by windows will remain valid.

%HOMEPATH% - points to the home directory of the currently logged in user. This path will always be writable to the user so you won't have permissions issues if the users will be installing the software themselves.

%HOMEDRIVE% - points to the drive that the system was installed on (usually C:, but can change). This is not the best option for installation, group policy often prevents users from writing here.

%PROGRAMFILES% - default program files folder, common place for installations.

MaQleod

Posted 2012-09-05T23:05:05.387

Reputation: 12 560

2+1: %APPDATA% and %TEMP% are two good ones as well. :) – Ƭᴇcʜιᴇ007 – 2012-09-05T23:29:52.717

Thank you. I will probably use HOMEPATH since the directory is intended for a user to place files in. – jpmc26 – 2012-09-05T23:34:03.383

Use the SHGetSpecialFolderPath() Windows API to retrieve the path corresponding to any of the various special folder symbolic names. For example, calling it on CSIDL_DESKTOPDIRECTORY guarantees to give you the localized name of the user's desktop directory. I used this API to build the directory utility included with my Hamilton C shell which, in turn, I use to know where to put things during installation.

Nicole Hamilton

Posted 2012-09-05T23:05:05.387

Reputation: 8 987

Useful, but unfortunately, this is going in a document, not code. (Hence why I asked on Super User instead of StackOverflow.) Thanks, though. Hm. Some documentation says that method is unsupported and to use ShGetFolderPath instead. Does that work just as well?

– jpmc26 – 2012-09-07T00:05:40.903

1I'll be darned. I wrote my code using SHGetSpecialFolderPath() ten years ago on Win2K. It was definitely documented as supported then and no matter what the docs say today, it's still works on Win7. But it does look like MS would like us to migrate to their newer API, SHGetKnownFolderPath(). Thanks for picking that out. – Nicole Hamilton – 2012-09-07T14:31:03.617