Share via

File and directory issues

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

File and directory issues

The files and directories a program creates and uses might present problems if the program was not originally designed for a multiuser environment.

Files that store per-user data

A program might use a single path for a file that contains per-user data. In some cases, this can mean that if one user updates this file, it affects all users. More severe problems include preventing multiple users from running the program simultaneously and corruption of the file, which can cause the program to fail for all users.

Note

  • Most files do not contain per-user data and are safe to share. Some files can be classified either way, depending on the system administrator's preference. For instance, document template files can be made read-only and safely shared. Or, users can have their own set of template files that they can update as desired.

If you have difficulty finding a shared file, you can use file auditing to track successful write operations.

Another path issue arises when programs store files in public directories such as systemroot. Some public directories have read-only permission for nonadministrative users, which prevents accidental modification of common files. However, if a program attempts to write a file into one of these shared directories, the program fails.

A frequent symptom of this problem is a program that can be successfully executed by an administrative user, but fails for a nonadministrative user. To isolate this problem, use file auditing to log all write operations that fail.

Some programs use temporary directories to store information that relates to the current user. The program might not create a separate directory for each user, thus causing temporary data for multiple users to be stored in a single location. If the program is not intelligent about handling this data, one user can delete data that is still needed by another user.

Updating the path

When you identify a file that stores per-user data, update the path so that a copy of the file resides in each user's home directory.

Programs can store a file path in several places, including:

  • HKEY_LOCAL_MACHINE

  • HKEY_CURRENT_USERS

  • A configuration file

  • Hard-coded within the program itself

Some per-user files are generated by the program. Other per-user files, such as document templates, must be provided for the user by copying them into the user's home directory. If you specified the path as a subdirectory of the user's home directory, you might need to create the subdirectory as well.

Per-user tasks can be performed in a script that is run during logon. The script checks the user's home directory to determine whether the files or directories in question already exist. If not, it can copy them from a master. Using a script allows you both to update current users with a new program and to set up new users.

Permissions and accessibility

Another path-related issue arises when a program cannot locate files in or below systemroot.

This problem occurs with some programs that use the GetWindowsDirectory() function to determine the name of the directory where Terminal Server was installed. Programs that use this function benefit from an automatic remapping. The function returns the Windows subdirectory of the user's home directory.

This automatic remapping can be disabled with a program compatibility flag. This is appropriate if the files under systemroot are being used only for read access. For more information about compatibility flags, see Program compatibility flags.