A coworker recently received his every two year work laptop refresh and was in the middle of loading his new laptop with Vista. For some reason, his hard drive C: was partitioned to only 25GB and the rest of the space reserved for a much larger drive D:.
Anyway, after loading many Windows Updates, he was left with hardly any drive space left on C:, and for some reason, the WinSxS directory had ballooned to over 8GB.
While I knew what the WinSxS (Windows Side-by-Side) directory was for, I wasn't quite sure why that directory would explode in size so fast with normal operating system updates.
A little digging and I think I have part of the answer, based on two different postings from MS's jonwin's blog. You can read the WinSxS specific posts
here and
here.
The most interesting and/or relevant sections of those posts, which explains quite a bit about the WinSxS directory:
Content is added to this directory in response to installing applications, enabling packages in the add-remove-programs UI, and installing Windows Out-of-Band releases. Content is removed from this directory as a result of uninstall + scavenging - a topic for another time. One important note - uninstalling your application or Windows app will not necessarily remove the physical bits from the system. The servicing stack marks the bits as unusable and prevents their use through "normal" means. Files and directories will be removed over time as the servicing system cleans up after itself. Administrators should not, for any reason, take it upon themselves to clean out the directory - doing so may prevent Windows Update and MSI from functioning properly afterwards. Preventing accidental deletion from the directory is accomplished by putting a strong security descriptor on the directory that inherits to its children.
In Windows Vista, the directory %windir%\WinSxS has much stronger protection on it than it did in Windows XP and Server 2003. The owner/group is now a SID named "Trusted Installer", a service SID used to start the TrustedInstaller service. Users other than the trusted installer are granted only generic-read/generic-execute by default. This increased protection ensures that only the trusted installer service is allowed to modify the servicing-related metadata and files. If a limited user could modify a file in the directory, for example, they could convince the servicing stack to overwrite one binary with another when the next administrator comes along to enable the Games for Windows package.
You may or may not have ever peeked into the %windir%\winsxs directory on your system. If you haven't, now would be a good time. First thing you'll notice is that there are a lot of those funkily-named directories. You might further notice that there seem to be several that differ only by what looks like a version number and some random-looking eight characters on the end of the name. Next you might see that some of them differ only by the second-to-last stringish thing. Lastly, note that mostly, the strings can be deciphered with a little help.
Each shared component (in the winsxs directory) gets its own directory into which its payload bits are placed. Somehow, we have to generate (mostly) unique & repeatable directory names for this purpose. The requirements of directory names are reasonably simple - can't overall be more than MAX_PATH (260) characters, can't contain certain characters, etc. Given the naming requirement, it was impossible to use the entire identity as the name of the directory, as someone could name their component "foo\bar" and mess things up. With the extensibility requirement for identities themselves, we couldn't possibly use the entire identity, as the set of tuples would end up being far longer than MAX_PATH. Most importantly, we wanted the directory names to be readable to your average administrator or PSS representative. Finally, generation of the keyform from an identity had to be fast.
My take on all of this:
There should be a way to move this directory out of the %windir% directory structure. This directory has a potential to grow pretty much unchecked over time. As it stands right now, it is a huge hard drive space hog on any default Vista install.
