| Date: | August 6, 2010 / year-entry #224 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20100806-00/?p=13213 |
| Comments: | 26 |
| Summary: | 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... |
Locations in the shell known folder system can be marked as This dichotomy appears simple and unworthy of discussion, except that customers sometimes have trouble incorporating this concept into their world view.
The difference is that
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:
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 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 |
Comments (26)
Comments are closed. |
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.
A disaster of biblical proportions – real wrath of God type stuff:
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!
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.
This is a symptom of people not understanding the whole picture. And most programmers are like this cause it takes time to gain experience.
@Pierre B.
Just try running updates after moving it. If "All users" is not on the system drive, updates silently fail to apply.
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
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.
@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.
@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).
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
The Shell Revealed blog was great, I hope it will return for Win8 with whatever new shell stuff is added for the version
The Shell Revealed blog was great, I hope it will return for Win8 with whatever new shell stuff is added for that version
Am I the only one (mis)reading the sentiment here? Or is it just my wishful thinking?
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.
@Johnny-boy: It's compiled as a CHM and made available here: code.msdn.microsoft.com/…/ProjectReleases.aspx
@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)
+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).
@Joshua
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
Therefore he's not mistaken, because he's saying just that and nothing else.
Except, of course, stuff created at the toplevel of the current user's home will still be on the system disk…
@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.
@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.
@davis omg I was wondering where that blog went, thanks.
@Leo Davidson: Vista and Windows 7 both create junctions from "C:Documents and Settings" to C:Users
Shell (explorer) cannot follow ntfs junctions :(
deny list-contents permission. -Raymond]
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)
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.
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.
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.
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+.