Should you delete files in the WinSXS directory? And what’s the deal with VSS? | Quisitive
Should you delete files in the WinSXS directory? And what’s the deal with VSS?
February 24, 2011
“Can I delete the \Windows\Winsxs directory to save space?”

Nice post over on TechNet by “Joseph”, there are some great comments below the post as well.

Read the original post here.

I like to read about how Windows is affecting peoples lives, specifically, the servicing components.  One of the common threads I noticed in my recent web trolling was the question “Can I delete the \Windows\Winsxs directory to save space?”.  This is usually asked in conjunction with what the directory does and why its consumed the space it has, but I’ve already covered that in prior posts.

So, to answer the question, the answer is simply: No.

Why?  Because the component store (\Winsxs) is needed to repair the OS binaries in the event that a file becomes corrupted or, in worst case scenarios, compromised.  There are a few directories in the component store so let’s look at them and what their general role is in Windows.

1.\Winsxs\Catalogs:  Contains security catalogs for each manifest on the system
2.\Winsxs\InstallTemp: Temporary location for install events
3.\Winsxs\Manifests: Component manifest for a specific component, used during operations to make sure files end up where they should
4.\Winsxs\Temp: Temp directory used for various operations, you’ll find pending renames here
5.\Winsxs\Backup: Backups of the manifest files in case the copy in \Winsxs\Manifests becomes corrupted
6.\Winsxs\Filemaps: File system mapping to a file location
7.\Winsxs\<big_long_file_name>: The payload of the specific component, typically you will see the binaries here.
So, can you delete these?  Sure, you could I guess.  What would happen?  Well, it depends.  So long as the files in the \Windows\System32 directory are valid, most likely you wouldnt see any problems initially, the machine would “most likely” operate properly.  However, the first time you attempt to update a binary, apply a service pack or service a component, it’s going to fail because the backing components needed arent there.  The way the files end up in \System32 are via hardlinks.  This should help answer another common question I see regarding how VSS is used in servicing.  Short answer: It’s not.  We use NTFS hardlinks to project the file to the file system from the component store.  That’s why the \Winsxs directory is so important.  The files there can be seen as the “authoritative” versions on the file system.  When you encounter an issue and that binary needs to be replaced, running an SFC /SCANFILE against it will check the directories above and if the version doesnt match, it will re-project it so that its working.

Here’s an example of how you can see the hardlink via CLI:

C:\Windows\System32\drivers>fsutil hardlink list ntfs.sys

This isnt the best overall example but its one I use often as a quick and dirty way to see the links in the OS.  You can see that the NTFS file has a link to the \Winsxs directory and if that version of NTFS were to become corrupted, we could go back to the component store and find you a new copy.  The backup directory in \Winsxs is there in the event that the version in that directory has also become corrupted.  It’s a good way of having protection on the OS without consuming a huge amount of space. 

Also, as Andre mentions in the comment below, its worth noting that the new servicing structure does remove the $NTUninstall$ folders that many people have become accustomed to from Windows NT to Windows 2003.  Updates, if they are marked removable, no longer contain that structure.  Instead, updates are recommended to be removed via the Control Panel –> Programs  –> View Installed Updates path.  You can remove the updates via the appropriate switches in DISM.EXE or PKGMGR.EXE, but the control panel method tends to be cleaner.

Hope that helps.