Anyone who likes their Documents folder to contain only things they place there knows that the standard Documents folder is completely unsuitable for this task. Every program seems to want to put its settings, data, or something equally irrelevant into the Documents folder, despite the fact that there are folders specifically for this job1.

So that this doesn't sound empty, take my personal "Documents" folder as an example. I don't ever use it, in that I never, under any circumstances, save anything into this folder myself. And yet, it contains 46 folders and 3 files at the top level, for a total of 800 files in 500 folders. That's 190 MB of "documents" I didn't create. Obviously any actual documents would immediately get lost in this mess.

My question is: can anything be done to improve the situation sufficiently to make "Documents" useful again, say over the next 5 years? Can programmers be somehow educated en-masse not to use it as a dumping ground? Could the OS start reporting some "fake" location hidden under AppData through the existing APIs, while only allowing Explorer and the various Open/Save dialogs to know where the "real" Documents folder resides? Or are any attempts completely futile or even unnecessary?

1For the record, here's a quick summary of the various standard directories that should be used instead of "Documents":

  • RoamingAppData for user-specific data and settings. This is the directory to use for user-specific non-temporary data. Anything placed here will be available on any machine that a given user logs on to in networks where this is configured. Do not place large files here though, because they slow down login/logout in such environments.
  • LocalAppData for user-and-machine-specific data and settings. This data differs for every user and every machine. This is also where very large user-specific data should be placed.
  • ProgramData for machine-specific data and settings. These are the same regardless of which user is logged on, and will not roam to other machines in a network.
  • GetTempPath for all files that may be wiped without loss of data when not in use. This is also the place for things like caches, because like temporary data, a cache does not need to be backed up. Place your huge cache here and you'll save your user some backup trouble.

"Documents" itself should only ever be used if the user specified it manually by entering a path or selecting it in a Save dialog. That is the only time it is ever appropriate to save stuff in "Documents".

  • Discussion on this thought should be taken to meta.PE.
    – Josh K
    Commented Feb 15, 2011 at 20:38
  • "Could the OS start reporting some "fake" location hidden under AppData through the existing APIs, while only allowing Explorer and the various Open/Save dialogs to know where the "real" Documents folder resides?" Anything that reduces the power of the users is bad. And by users I mean users who know how to program for automation. Commented Feb 15, 2011 at 23:32
  • 1
    I feel the need to clarify that the Documents folder on all my computers is free of junk, because I run Linux boxes. I know this is tagged 'Windows', but nowhere in this glorified rant did you mention what OS you use. Commented Feb 16, 2011 at 10:19
  • 1
    Clearly the problem here lies with Microsoft allowing this to happen and even promites it - look at Visual Studio / SQL Server Management Studio. An interesting Question is - is there a good place to rant at Microsoft regarding this problem? Commented Dec 2, 2015 at 12:26
  • 1
    Current OneDrive settings make this even worse. Because it's setting the Documents folder inside OneDrive (which is actually a nice idea). But I just had 1 hour almost no internet, until I noticed Xamarin thought it would be a nice idea to push Android NDK into my (OneDrive) Documents folder. My other 3 synced computers automatically downloaded all the files. 1.9 GB...
    – Matt
    Commented Dec 10, 2015 at 14:17

8 Answers 8


There would need to be some visible incentive. For example, if users had to provide permission to save in the Documents folder (at install time), programmers would want to avoid triggering that scary dialog.

Once you have the incentive, people will naturally stumble upon documentation like "Save machine-specific program data in ProgramData" while trying to solve it.

Actually, a lot of problems could be solved by a nice permissions framework...

  • Sound a bit like the Apple sandbox for Mac OS X : You can only save in a arbitrary location by going through an OS Controlled dialog that allow you to select the save location. If the user click OK, it unlock the directory for future use. Commented Dec 20, 2013 at 16:21

My question is: can anything be done to improve the situation sufficiently to make "Documents" useful again, say over the next 5 years?

In theory, something could be done. In theory Microsoft could:

  • Come up with a better place to put user setting files (in the process, recognizing that a lot of applications have valid reasons to put settings in files).
  • Add this to the standard Windows application developer guidelines. (I assume such guidelines do exist.)
  • Make a big thing about applications conformance to the guidelines, e.g. via some kind of certification or by creating and publishing conformance scorecards. "Naming and shaming" could work wonders ...

It must be said that Apple has traditionally been much more proactive with this kind of thing. And it shows in the quality of the stuff that runs on their platforms.

  • 4
    It's worth noting that Microsoft is a big offender itself (or, at least, some Microsoft teams are big offenders). Commented Feb 16, 2011 at 13:09
  • Totally agree with the "big thing" point. As for a better place - I think the roaming profile is not too bad already, it's just that there are too many people who don't know of it, or worse, put huge (2GB+) files in there. Especially games... Commented Feb 16, 2011 at 13:34

I think you answer the question in that it boils down to programmer education. I don't know enough about the Windows API and if storing stuff in Documents is particularly easy, but if not then applications shouldn't pollute it. I think it comes down to having a per-user known location where data can reside. For the sort of data you talk about, Mac OS X uses the ~/Library folder, though some apps still stick things under Documents. Maybe something similar should (does?) exist for Windows.

Personally, I keep my Documents on a same-titled folder under my Dropbox root, which does add an extra level of work for me, but saves me from the problem you've raised.


Though I understand you want to engage in a discussion about getting developers to stop doing this, it might wind up becoming one of those things like taskbar notification icons which couldn't be stopped so Microsoft just swept them under the rug.

I have previously blogged about the Documents folder, likening it to moving out of a bad neighborhood. As a user, I came up with a bunch of hacks for trying to clean it up on my own. I would mark all of the uninvited folders as "hidden" which would make them disappear from Explorer. I would create symbolic links for Visual Studio 2005, 2008, 2010 folders into a common "Visual Studio" folder, etc.

But even with PowerShell scripts to automate it, I got sick of doing it on every new machine I used. Fortunately, in Windows 7 there's another option that works pretty well for me.

Since Windows 7 tends to default to the "Documents" library as opposed to the Documents folder. I've simply removed the %userprofile%\documents folder from this library and instead added my Dropbox folder. So now open/save dialogs default to this location and when I click Start -> Documents, it takes me to my Dropbox.

Ultimately, I'd love to see some kind of basic certification for apps similar to the iOS App Store guidelines. But they can't even get driver manufacturers to sign their drivers...

  • 1
    So in other words, you think that nothing can be done to salvage it, but it's OK because there are better ideas floating around. +1. Commented Feb 23, 2011 at 10:57

I think the long-term strategy should be to stop storing anything other than documents in files. System data, especially settings, should be stored in storage systems that resemble a database more than a file system. Bonus points if that database can be easily and automatically synched with a service on the web, so you effectively have one set of settings irrespective of how many computers you use and where.

I don’t know much about the history of file systems, but it seems to me that it was realised pretty early on that system and executable files are a fundamentally different “thing” than documents. So those got stowed away in a special folder (then called directory) like C:\DOS and the user was basically in control of the rest of the drive.

Nobody really predicted how much more complex and unmanageable systems would become over the years and what a mess this would make. I think it is time to rethink the technology from the grounds up and leverage the synergy of the cloud. Bonus points if a workable open-source solution takes off before a company does it :)

  • 3
    Wouldn't it make more sense to do the opposite, i.e. to store only system stuff as files, and have user data available in databases, especially if synced through web services? Commented Feb 15, 2011 at 20:22
  • 1
    Hm, the details certainly need some fleshing out... but the real point I was trying to make is that only documents in the real term (i.e. files that a user actually works on that have nothing to do with running the system) really fit into the metaphor of the file.
    – Timwi
    Commented Feb 15, 2011 at 20:23
  • Also, I'm not sure this addresses the issue. If programs have access to the storage system dedicated to user documents, they can still put their junk there. What is required is something that stops programs doing this, either through technical means or by getting programmers to just stop voluntarily. Commented Feb 15, 2011 at 20:24
  • The register was such a system and it didn't work out so well. I don't think the appdata approach where programs store files with their own settings is that bad.
    – Pieter B
    Commented Dec 20, 2013 at 9:16

Even if some program still store some data in Documents, I think most store their data in AppData instead, so they're already going in the right direction imho, however there isn't much users can do: each program is responsible for what it does.

  • 1
    I agree; users are helpless. This can only be solved by programmers. Commented Feb 16, 2011 at 9:01

1. Right Click 'Documents' folder and select the 'location' tab.
2. Change the 'Documents' location to some other place I choose 'C:\Admin\Configs' (once this is done, all applications, writing to 'documents' should be sent off to C:\Admin\Configs instead.

But this solves only half the problem, the next step should be pretty obvious.

  1. Create a new folder in 'C:\User\\Documentation'

You should be able then to add that directory to the libraries and delete the old one, I deliberately set a different folder name in 'C:\User\**Documentation**' because I wanted to ensure nothing could just hard path to that folder.

Should the folder 'documents' appear again in your C:\User\ because of the above fact, simply right click the folder and make it an invisible folder.


Storing settings in a text file is a catch-all cross-platform solution.

Unless developers were to create a cross-platform settings database standard, I think most of us will keep using text files dumped to the user directory.

Those of us who are smart will create different settings interfaces for systems which allow specialized settings storage engines (such as the Windows Registry).

  • 1
    Note that the "Documents" folder is not the "user" directory. The "Documents" folder is a sub-directory of the user's directory, the intention of which was supposed to be where the user saved his own documents. The problem is that programs decided to put their stuff in the "Documents" folder as well, even though there are better (and documented as such) places for program settings to go. Commented Feb 16, 2011 at 3:06
  • 1
    This is a good example of one path towards Documents mess. People port a program without knowing much about Windows, and dump their stuff in the first directory that comes to mind. It's probably much easier to find "Documents" than it is to find "AppData", especially since the latter involves deciding whether to put it into the roaming or local profile - unfamiliar terms to anyone not deeply involved with Windows development. Commented Feb 16, 2011 at 9:02
  • Agreed, and again - the real solution is to have a standard cross-platform settings storage engine.
    – Craige
    Commented Feb 16, 2011 at 15:08
  • 1
    Not going to happen. The original question is about re-educating all Windows programmers, and your answer is to re-educate every programmer. Nor are you going to get Unix/Linux programmers to buy into a settings database, because there are very good reasons to leave these as text files, and you will face additional resistance to doing things the Microsoft way. Commented Feb 23, 2011 at 15:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.