| Date: | July 1, 2005 / year-entry #170 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050701-09/?p=35133 |
| Comments: | 21 |
| Summary: | The most important difference between My Documents and Application Data is that My Documents is where users store their files, whereas Application Data is where programs store their files. In other words, if you put something in CSIDL_MYDOCUMENTS (My Documents), you should expect the user to be renaming it, moving it, deleting it, emailing it... |
The most important difference between My Documents and Application Data is that My Documents is where users store their files, whereas Application Data is where programs store their files. In other words, if you put something in CSIDL_MYDOCUMENTS (My Documents), you should expect the user to be renaming it, moving it, deleting it, emailing it to their friends, all the sorts of things users do with their files. Therefore, files that go there should be things that users will recognize as "their stuff". Documents they've created, music they've downloaded, that sort of thing. On the other hand, if you put something in CSIDL_APPDATA, (Application Data), the user is less likely to be messing with it. This is where you put your program's supporting data that isn't really something you want the user messing with, but which should still be associated with the user. High score tables, program settings, customizations, spell check exceptions... There is another directory called CSIDL_LOCAL_APPDATA (Local Settings\Application Data) which acts like CSIDL_APPDATA, except that it does not get copied if the user profile roams. (The "Local Settings" branch is not copied as part of the roaming user profile.) Think of it as a per-user-per-machine storage location. Caches and similar non-essential data should be kept here, especially if they are large. Other examples of non-roaming per-user data are your |
Comments (21)
Comments are closed. |
Raymond,
where should an application that writes plaintext log files write its log files? CSIDL_LOCAL_APPDATA? What directory should be used, if customers expect to find all log files in a single directory, even if the log files are created by different processes running under different principals (such interactive processes, services running under SYSTEM or under a distinct user account)?
—
Stefan Kuhr
Where should chat-logs (irc, instant messenger) be stored?
I use 2 applications that store them in APPDATA, but in my opinion they should better be in MYDOCUMENTS?
What do you think?
hi: Personally? I’d not save logs unless the user asks to have the logs saved.
And then, when the user asks to save the logs, prompt them and let them make the choice.
Stefan, %TEMP%? Why not use WMI events and let them go to the bit bucket unless the user’s running an app to collect the logs? Disk space is cheap, but it isn’t free..
All my opinions, but I don’t know your app.
More and more applications store data in "My Documents" than in "Application Data". I don’t like applications to store data there… ICQ, WebShots, Skype, Whidbey (eben Microsoft products), MSH (aka Monad, the new "console"), … store there data!
It’s not good behaviour for an application to store their information into "My Documents". Should be "My" and not "Their Documents".
We use folder redirection and we were redirecting app data to a server. But some apps malfunction within this scenario, so we decided to take the worst option available and use it (we redirect the app data back to the local workstation) This causes more headaches then its worth, it no longer is included in the users roaming profile. It should just roam with the users.
I wish the makers of The Sims 2 understood this :(
EA is bad at this. A number of their games (I have personal experience with both C&C: Generals and Battlefield 2) store their user profile files in My Documents. 90+% of users will never want to view or edit these files (they’re used to store options that are generally set in the game’s UI), so they’re just clutter.
Still, that’s better than Valve; Half-Life 2 was released last November, yet Steam still stores user files in its install directory (which of course defaults to Program FilesSteam)…
And just for the trifecta of uselessness, BF2 at least, and possibly HL2 as well, uses Punkbuster, which requires that the user run as Administrator.
Stefan:
Use the shared documents for that. You’ll see Dr. Watson and Application Compatibility, both of which create log files from all user accounts in a single directory, use it
Raymond:
While we’re on the topic of Application Compatibility and user folders… any idea why LUARedirectFS doesn’t work anymore at all in Windows Server 2003? I mean, I see aclayers.dll and aclua.dll being loaded, but it doesn’t appear to work at all. And the HighVersionLie mode of Application Verifier is likewise broken – it used to work even on msiexec.exe, now I can’t get it to do a thing even with winver.exe. I’m running Terminal Server, could its compatibility layer be interfering?
The Application Compatibility Layer should be documented a little better, it still feels a lot like an internal tool released as an afterthought (especially Compatibility Administrator – no way to edit certain databases or certain application fixes, such as patches; and who knows what the command line syntax of most of fixes is?)
Video game makers should take note of this. One of the only reasons that I can’t run a game in a limited account is because they put the save data in Program Files
This discussion got me thinking about my n-tier systems and their server side in particular.
My servers read/save their settings to a file right beside the executable. The reason being that they can run either as a service or as a regular desktop app. This can sometimes even change after the inital instalation, so there is an obvious problem with using profile’s folders.
Furthermore, servers must support everything from NT4 to Win2k3, which all really quite differ from one another in respect to profile locations. I imagine it’d be really hard for the support team when they had a nervous client on the phone, mumbling about "problems", and they needed to ask him to locate a specific profile in order to view the settings that broke the application.
Where do you recommend settings for such applications should reside?
Logs are a similar issue. I wouldn’t want to take the route Larry is suggesting for messaging applications, namely only saving logs when user wants to. Obviously, logs are important for our support team when diagnosing problems, so they must be saved somewhere, preferably in an easy to find location. To me, text files seem to be the most practical solution, even for services, because they are easily portable (i.e. same type of output on any OS).
So, where should logs go?
Gene,
Note that in the cases of games trying to write stuff to their installation directories, you can often make them happier by simply changing the permissions on the directory to allow write access there alone. This means that only the game directory is vulnerable to whatever you’re preventing by running as a normal user account.
Of course, if you’re using Windows XP Crippleware Edition you’ll have to set the permissions using the command line tool CACLS rather than the pretty, clicky-ticky UI.
Re: Games writing to their installation directory —
Can’t you change the installation directory during, um, installation? Only subdirectories of "Program Files" (and some other special folders) are protected. Install the game somewhere else, and they can write their data just fine even under a limited account.
Speaking of EA, BF2 and hopeless Windows integration… (sigh)
BF2 refuses to run on my system. It complains I’m using CD emulation software, but after uninstalling Daemon Tools I’m no longer running such software (and it is useful software btw! grrrrr).
After a long support session with EA, their conclusion is that it would’ve worked had I run Windows XP. (I use 32-bit Windows 2003 Server)
I’m tempted to install Windows XP only to prove them wrong, but I’m settling in with the no-CD crack provided by some pirates. The pirate community seem to write better software than the content providers…
(And with content providers like these, I’m starting to think that next time I’ll simply pay the pirates instead — I get the same amount of tech support and seemingly much less problems. Are content providers like EA even serious about fighting piracy? They act like an evil villain from a James Bond movie!)
I just wish MS was as big and menacing as some people think. It would be nice to sink MS on EA’s ass and let them know it is not cool to forsake Windows 2003 support (nor 64-bit XP for that matter, I’ve read that you’ll need the no-CD crack for that one too). However, the big surprise for me is that the OS actually ships with the SafeDisc driver (secdrv.sys) pre-installed! :(
Raymond,
Thanks for this explanation. It couldn’t have been more timely as far as I’m concerned. I’m starting to add a ‘check for updates’ feature to an app and planned to fallback on AppData to store these files if user doesn’t have write access to Program Files.
But I didn’t know the exact difference between AppData and Local AppData. Since the data is fairly big (a few MBs), I now realize that I should better save it to Local AppData.
So why does Outlook by default put its PST files under Local SettingsApplication Data? And why is the Local Settings folder hidden by default? This unfortunate combination means that users often can’t find, and don’t back up, their PST files.
I suppose that (Common) Program Files should only be written to during installation while Application Data can be written at any time.
Right?
Is there any reason for an application itself (i.e. not its installer) to write in the Program Files folder? [Except Aleksander’s use case]
Andy: I don’t think so. Even in Aleksander’s case, a production application should probably allow the location of log files and such to be configurable. I mean, in a production environment, you’re probably going to want your log files on a separate disk altogether, to avoid contention just writing logs all the time.
Even an "administration" application, which usually requires admin privileges anyway should be designed so as to write all app-specific data to Application Data. Most admin tools allow for remote access anyway, so while you’d probably need to be an admin on the remote machine, you don’t necessarily need to be an admin on the *local* machine.
dc: PST files go into Local Settings so they aren’t copied as part of the roaming profile to the network.
With PSTs regularly hundreds of Megs (and Outlook touching the file each time they’re opened), you don’t want to be copying them back and forward to the fileserver all the time.
It’s probably to late to post this, but…
@ Ben, Chris
Of course there are ways around this. I choose to run as admin for games. However, a normal user might have trouble doing what you propose. Software should just "work".
Don’t create clutter.
PingBack from http://www.gno.se/blog/?p=26