What are the recommended locations for storing different types of files?

Some time back, I provided informal guidance regarding what types of files go into which folders. Here are the official guidelines [pdf], for those looking for something with more authority than just me blathering.

Comments (19)
  1. Joshua says:

    C:UsersusernameAppData (hidden)

    C:ProgramData (hidden)

    Stop the hidden files & folders creep and maybe people won't turn on "Show hidden files & folders" then complain about desktop.ini on the desktop.

  2. @joshua says:

    Did you not read Raymond's first link? They're hidden because those folders are for PROGRAMS to store data. Data that you expect USERs to play with should be stored in My Documents, which is not hidden by default.

  3. Bob says:

    This document states that it applies to Vista. Since Raymond is providing a link to this, I guess nothing changed for Windows 7. Is this correct? I'm asking because I avoided Vista and went straight to Windows 7 when I built my new PC.

  4. Mason Wheeler says:

    @Joshua: I'll accept that as valid when they provide an easy way to get to the magic folder that programs written before Vista reach when they try to save a file somewhere under Program Files.  Sometimes those are documents that the user needs to be able to get access to.

  5. Jake says:

    How does this advice change with respect to the Libraries introduced in Windows 7?

    Specifically, the document recommends creating a new data folder at the root of the user's profile.  With the Libraries in Windows 7, would the recommendation change to creating and leveraging a Library with the default-write location as previously recommended?  Or is the creation and use of Libraries a user-specific function?

  6. Joshua:

    The thing is, unhiding appdata and programdata doesn't show desktop.ini, you need to use a completely different option to show desktop.ini. (It is a protected operating system file.) So if anyone is showing these and getting desktop.ini then it is obvious that they are doing something wrong.

  7. skSdnW says:

    @Bob: 7 added FOLDERID_UserProgramFiles for per-user installs like Chrome and Live Mesh.

  8. Nick says:


    Desktop.ini files are only shown if you also un-check the "Hide protected operating system files" box in Folder Options.

    I used to always choose "show hidden files" and "show protected files" — dealing with the annoying desktop.ini files all over the place — until one day I stopped and asked myself why I was even bothering with it.  Since then I've left the "Hide protected…" option checked, and using Explorer is much more enjoyable than before.

    Give it a try.  You can still see all the hidden files and folders so navigation is easy, but aren't bothered by files that are extraneous 99.99% of the time (e.g., desktop.ini, System Volume Information, etc).

  9. alegr1 says:

    "Show hidden files/folders" should be a button that appears every time there are those in the current folder. It's too much hassle to enable when necessary, and too much clutter when you don't need them.

  10. @alegr1 says:


    Your wish has been granted in Windows8.

  11. The best way to get developers to use the correct folders is to produce a 16 page document they won't know about or likely bother reading.

  12. xpclient says:

    There seems to be no KNOWNFOLDERID for what Explorer shows as "Recent Places".

  13. Joshua says:

    Well it turned out it was my turn to take a beating. Protected operating system files are no longer being abused and so that setting is be safe to turn off (ages ago that used to hide a bunch of programmer file types).

    My point about the hidden file creep still stands. Application data folders are exactly what you *don't* want hidden because many applications store actual data (not just cache data) there and so you really do want to see it (to back it up if nothing else). The old quote of "Where's your music?" "In Kazaa." really did indicate something that needed better handling.

  14. Kaso says:

    I've read through this document and stil don't quite understand what AppDataLocalLow is for. It doesn't seem to give any examples for this one like it does for the others.

  15. Matt says:


    LocalLow is the user's roaming profile that is accessible to low-integrity processes like Internet Explorer. This means that processes that are at heightened risk of being hacked (like your browser, PDF readers etc) can write data to there, but can't steal or attack other critical files in your roaming profile.

  16. Joshua says:

    @alegrl1: There's nothing stopping you from handling WM_NCPAINT from an AppInitDLL or some other mechanism to change the look of the thing (no it's not as easy as it sounds). Now the Metro application system on the other hand …

  17. Danny says:

    When the day will come and the viruses/malware etc apps will start follow this guidelines will be the day I will too…till then I am forced to NOT follow it!

  18. Evan says:

    @Danny: What does what malware does have to do what you do?

  19. skSdnW says:

    @xpclient: Its undocumented? path is shell:::{22877A6D-37A1-461A-91B0-DBDA5AAEBC99} and can be parsed by SHParseDisplayName and explorer.exe. It is just a filtered (SHELL32!CRecentDocumentsFolder::ShouldEnumerateTarget) view of FOLDERID_Recent. The shellfolder registration also uses the undocumented RestrictedAttributes and WantsUniversalDelegate values…

    [Yes, it's undocumented. Just because it has a path doesn't mean that it's documented. -Raymond]

Comments are closed.

Skip to main content