Some known folders cannot be moved, but others can, and you’ll just have to accept that


Locations in the shell known folder system can be marked as KF_CATEGORY_FIXED, which makes them immovable. Conversely, if a file system folder is not immovable, then it can be moved.

This dichotomy appears simple and unworthy of discussion, except that customers sometimes have trouble incorporating this concept into their world view.

I have some code that calls SHSet­Folder­Path, and it works for most of the folders I'm interested in, but for some CSIDL values like CSIDL_COMMON_APPDATA, it fails with E_INVALIDARG. Doesn't matter if I run elevated or not. What am I doing wrong?

The difference is that CSIDL_COMMON_APPDATA (known under the New World Order as FOLDERID_ProgramData) is marked as KF_CATEGORY_FIXED so it cannot be moved.

Is there a way that we can override the KF_CATEGORY_FIXED flag and move it anyway?

Nope. It's immovable. Sorry. You'll just have to accept that that folder will not go where you want it.

The very next day, we got a complementary question from an unrelated customer:

We have a program that monitors a known folder, and it goes haywire if the user changes the location of the folder while it's being monitored. Is there a way to prevent the user from moving the folder?

If a known folder can be moved, then you have to accept that it can be moved. You can't override its category and force it to be KF_CATEGORY_FIXED just because your life would be easier if it were.

I found it interesting that we got two requests on consecutive days asking for what appear to be opposite things: "I want to force this folder to be movable" and "I want to force this folder to be immovable." I can only imagine what would happen if both programs are running at the same time!

What the program can do is register an IFile­Is­In­Use on the directory so that it will be called when somebody wants to move it. At least that way it knows when scary things are about to happen and can prepare itself for the changes that lie ahead. I'm told that a sample program illustrating IFile­Is­In­Use is in the Windows 7 SDK under the directory winui\Shell\AppPlatform\FileIsInUse. There's also an old article on the subject over on the now-defunct Shell Revealed blog.

Comments (26)
  1. Joshua says:

    Unfortunately C:Users is KF_CATEGORY_FIXED.

    If you really need the location of "All Users" and "Default User" to be on the system drive, fine. However, there is no excuse for requiring the per-user folders to be there.

  2. mikeb says:

    > I can only imagine what would happen if both programs are running at the same time!

    A disaster of biblical proportions – real wrath of God type stuff:

    • Fire and brimstone coming down from the skies! Rivers and seas boiling!
    • Forty years of darkness! Earthquakes, volcanoes…

    • The dead rising from the grave!

    • Human sacrifice, dogs and cats living together… mass hysteria!

    It's a good thing that Windows prevents these category attributes from being changed!

  3. Pierre B. says:

    KF_CATEGORY_FIXED only mean fixed for the current system boot. (Approximately.) OTOH, it also flags the folder as being very hard to move successfully. You can move c:users, but it's very hard as you have to update a lot of references to it, a lot of registry entries, etc. So even if it didn't have KF_CATEGORY_FIXED, moving it is not as simple as you seem to think.

  4. tobi says:

    This is a symptom of people not understanding the whole picture. And most programmers are like this cause it takes time to gain experience.

  5. Joshua says:

    @Pierre B.

    Just try running updates after moving it. If "All users" is not on the system drive, updates silently fail to apply.

  6. me says:

    This is a symptom of people not understanding the whole picture.

    The shell folder system has become quite complex over the years. IMO, the whole concept of virtual folders hasn't been a good idea from the beginning. Mixing a regular file system objects with virtual items (Desktop) is source of confusion for many users. I'd prefer a situation where there would only be regular folders, and programs would only be allowed to write to folders

    • in which the user explicitely installed them (somewhere in the user's profile),
    • to which the user moved them by hand,

    • which the user specified in an "Open" or "Save" dialog box.

    Everything else should be kept in the pagefile, as it is probably not data the user wants to keep on the long term.

  7. kog999 says:

    @Joshua "Unfortunately C:Users is KF_CATEGORY_FIXED"

    I'm imagining some lazy developer trying to rename C:Users to C:Documents and Settings so that his app designed for XP with a hardcoded path would work.

    Also for the person who wanted to make the folder immovable he could use a ACL on the folder. though quite frankly how often does an end user rename this "Known Folder". I'm assuming this isn't a folder located on the users desktop or my documents so if they start moving it for no good reason they deserve the program to crash.

  8. Leo Davidson says:

    @kog999: Vista and Windows 7 both create junctions from "C:Documents and Settings" to C:Users for just that reason (apps/scripts using hardcoded paths).

  9. asf says:

    Well, you can set the paths for the profile root, program files etc at install time with tools like nLite, after that if you move them there is too much fixup needed in the registry and config files

  10. WndSks says:

    The Shell Revealed blog was great, I hope it will return for Win8 with whatever new shell stuff is added for the version

  11. WndSks says:

    The Shell Revealed blog was great, I hope it will return for Win8 with whatever new shell stuff is added for that version

  12. Jack Russel says:

    New World Order

    Am I the only one (mis)reading the sentiment here? Or is it just my wishful thinking?

  13. Johnny-boy says:

    Does anyone know if there was a proper archive of the Shell Revealed blog before it got taken down? The archive.org version is hit-or-miss, especially with images/diagrams, and I feel like I missed out on a very good thing.

  14. davis says:

    @Johnny-boy: It's compiled as a CHM and made available here: code.msdn.microsoft.com/…/ProjectReleases.aspx

  15. Jim says:

    @Joshua:  Assuming I'm understanding your first comment correctly, you're partially mistaken.  It's true that the user folders are stuck in C:Users, but user data is not – you can move the documents, etc. folders anywhere you want.  See http://www.zdnet.com/…/215 (for Vista, but works in 7)

  16. someone says:

    +1000000 for start a new shell revealed blog. It was far better than OldNewThing (don't mind Raymond). Unfortunately, we never got the opportunity to really give any feedback on that blog as it started and closed down in an era when Vista's uptake was miniscule and there was no service pack (the abomination that was Vista RTM).

  17. Masklinn says:

    @Joshua

    Unfortunately C:Users is KF_CATEGORY_FIXED.

    If you really need the location of "All Users" and "Default User" to be on the system drive, fine. However, there is no excuse for requiring the per-user folders to be there.

    Completely agree, it's a pain, and likewise for all of the program files folders. You can actually move them and use links from c:Users to someOtherLocationUsers, but it was a damn pain (and I didn't have the courage to go through it again for program files, program files (x86) and programdata)

    @Jim

    Assuming I'm understanding your first comment correctly, you're partially mistaken.  It's true that the user folders are stuck in C:Users

    Therefore he's not mistaken, because he's saying just that and nothing else.

    but user data is not – you can move the documents, etc. folders anywhere you want.

    Except, of course, stuff created at the toplevel of the current user's home will still be on the system disk…

  18. AndyC says:

    @masklinn, in Vista and above there is a Group Policy setting to prevent users from saving or creating files in the toplevel of their homespace, thus ensuring they have to use one of the redirected folders instead.

  19. Joshua says:

    @AndyC: If you set that you must also set the users home directory to something writeable. This shouldn't be an issue if you can do the other stuff.

  20. Dan Bugglin says:

    @davis omg I was wondering where that blog went, thanks.

  21. Superdude says:

    @Leo Davidson: Vista and Windows 7 both create junctions from "C:Documents and Settings" to C:Users

    Shell (explorer) cannot follow ntfs junctions :(

    [Explorer tries to follow them, but those junctions
    deny list-contents permission. -Raymond
    ]
  22. joalex says:

    I've used junctions on XP for many years to move my user folder inside 'Documents and Settings'/'Users' off to a second drive. Actually, all discrete user accounts are junctioned off to another drive.

    Are we saying this can't be done on Vista/7? I somehow very much doubt this. All the drivers are in place by this time. It's a hassle to log in to the Administrator account to run a mklink, sure, but there's a reason you're a power-user that cares about these things.

    Isn't some user-profile location stuff also a GPO?

    @Superdude THOSE junctions it can't follow, sure. But I have several junctions on my Win7 workstation that point my Outlook folder to a mapped drive-letter which in-turn is mapped to a network fileserver. I can follow the links just fine just double-clicking on the junction-ed folder in Explorer. Explorer even shows that it's a 'shortcut.' Shared workstations breeds ingenuity.

    I have a feeling that the Docs&Settings and other related junctions are 'special,' and were created that way to not forward for various reasons (as noted by the 'padlock' overlay when unhidden in Win7)

    [I wrote about this some time ago. -Raymond]
  23. JM says:

    The comments regarding the Users folder are very interesting.  I got into trouble with that not too long ago.  My system volume was failing (getting S.M.A.R.T. warnings).  I wanted to get a backup of everything in Users, so I used (either robocopy or xcopy, can't remember which) to copy to a backup volume.  It went into some kind of an infinite recursion (I assumed due to junction points — psychic debugging??).  The weird issue I have now is that I cannot delete the directory structure from my backup drive!  (path too long — many repeating subtrees).  I assume that if I can find the junction points, I can delete them and then remove the path.  I'm not completely sure how to proceed, though.

  24. James Schend says:

    JM: I had that exact same issue. If you're using Robocopy (the one I used) to back up your /Users folder, *do not* run it as Admin.

    With Administrative permissions, it'll successfully follow the Documents and Settings junction continuously, eventually creating a folder structure much, much longer than Explorer can cope with, making it a huge pain to delete. (I actually just formatted the entire drive to get rid of the damned thing, since it was a blank drive anyway.)

    Without Administrative permissions, the protection Raymond talked about in the comment here applies: [Explorer tries to follow them, but those junctions deny list-contents permission. -Raymond] and the recursive loop doesn't occur.

  25. Marquess says:

    Actually, you can just run robocopy with /XJ (exclude junctions). But seriously, a real backup program (the one in Windows should be fine) is what you need here.

  26. Auntie says:

    On XP, I rename "Documents and Settings" folder to "Users" prior to OS install with Program XYZ since 2006, just for the brevity of it, and never had any problem. Sure, there were some apps hardcoded to "Documents and Settings", but they happily created the structure and wrote whatever they wanted to and worked fine. I abandoned them ASAP, but it wouldn't have been too hard to live with it or bug the developers. Also, Microsoft could have written a few shims for its most important partners/business apps.

    Just compare that with the mess on Vista+.

Comments are closed.

Skip to main content