B
BenGameDev
Guest
For those who are unaware, modifying the default storage path for an individual application (or all applications) downloaded through the Windows Store, will result in a protected "WindowsApps" directory/volume being created at the specified path (i.e. "D:" will become "D:\WindowsApps"). Unfortunately, even if this directory/volume becomes inactive (i.e. no applications utilise it), it cannot be removed (well, it can be removed, but will cause system instability, read below for further details).
I've attempted to remove the inactive "WindowsApps" directory/volume by doing the following:
1) Set the default storage path for applications to "C:" ("Settings", "Save Locations", "New Apps Will Save To...").
2) Ensured no applications are installed to "D:" ("Settings", "Apps & Features", Filter "D:").
3) Took ownership of the directory/volume ("Properties", "Security", "Advanced").
4) Set the relevant registry keys back to default values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes: "DefaultVolumeKey" = 1, "EnableExternalVolumes" = 1.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\1: "Default" = Null, "Flags" = 2, "MediaId" = Null, "MountPoint" = Null, "Name" = Null, "SISPath" = "C:\Program Files\WindowsApps".
5) Removed unnecessary registry keys (which are created and increment in value — based on the "NextVolumeIndex" DWORD — whenever a new directory/volume is specified):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\2.
6) Performed the equivalent of steps 1-5 through an elevated PowerShell window (using "Set-AppxDefaultVolume", "Get-AppxPackage", "Add-AppxVolume", and "Remove-AppxVolume").
7) Removed/recreated the directory/volume through the recovery command prompt.
8) Removed/recreated the directory/volume through safe mode.
9) Removed/recreated the directory/volume through Linux (using a live CD).
10) Enabled and used the elevated "Administrator" account (by using "net users Administrator /active:yes" in an elevated command prompt).
11) Enabled and used the elevated "SYSTEM" account (by using "psexec -i -s cmd.exe" from System Internals in an elevated command prompt).
12) Assigned a different drive letter (i.e. "D:" became "E:"), even though the volume identifier remained the same.
13) Removed/recreated the partition.
Steps 1-6 (and 12) all resulted in "access is denied" errors. Steps 7-11 all allow the "WindowsApps" directory/volume to be removed and recreated, but not cleanly. If the directory/volume is removed using these methods, and the "WindowsApps" directory is recreated manually (i.e. through File Explorer "explorer.exe"), it will result in system instability (i.e. process not responding). If the directory/volume is recreated using these methods, the permission issues (i.e. "access is denied") return. It seems like a background process/service (which isn't active in safe mode) is locking the directory/volume, and preventing it from being removed/renamed or overwritten. So, the actual file permissions seem irrelevant. The only solution — as ridiculous as it is — is formatting the partition, but the term "solution" is used very loosely.
So, this illogical issue has wasted a significant amount of my time and effort. Why would I say "illogical"? Well, it doesn't make any logical sense as to why an empty and inactive — I repeat, EMPTY and INACTIVE — directory/volume cannot be removed. It could somewhat be justified if the directory/volume was active to prevent tampering, but even then, couldn't the integrity of the package contents simply be verified via checksums? The lengths Microsoft have gone to in order to prevent users modifying these directories/volumes is absurd. It's malware-like.
Now, this is more than just an inconvenience, it's a usability issue. There are legitimate reasons (other than tampering or reverse engineering) why users would need to access the "WindowsApps" directory/volume. The Windows Store allows users to purchase AAA games (such as Rise of the Tomb Raider), which can be quite large in size (in the case of Rise of the Tomb Raider, it's almost 30GB). SSDs have become a necessity for good computing performance (and, as a result, an acceptable user experience), but are still quite expensive based on capacity, which means most users are opting for boot/system disks in the range of 250-500GB. That doesn't stretch very far when a single game can occupy upwards of 10% of the total capacity. So, what happens when a user wants to archive (SSD -> HDD) the application/game (whether it's to increase free space on the SSD or because he/she needs to reinstall Windows)? Should they be expected to download the application/game again? [FYI, the download speeds through the Windows Store are so abysmal, it should be considered a form of torture.] Every notable digital distribution platform (GOG, Origin, Steam, Uplay, etc.) has the ability to backup, restore, and verify the applications/games (or worst case, use junctions), but nope, not Windows Store!
So, either Microsoft hasn't done any usability testing, or they're oblivious to how users would want to utilise a digital distribution platform, or perhaps they just don't care and would prefer to dictate how users should do their computing (considering there are several 3 month old discussions/questions bringing attention to this issue without resolution, this seems likely).
Anyway, it looks like I'll be downgrading back to Windows 7. There is no compelling reason to remain with Windows 10 (apart from DirectX 12, which isn't so appealing now that Vulkan is in the frame), but there are many compelling reasons not to (Convoluted settings — why split them between "Settings" and "Control Panel"? Poor emulation/support for DirectDraw. Privacy concerns. Taking computing control/freedom away from users. The list goes on.).
Continue reading...
I've attempted to remove the inactive "WindowsApps" directory/volume by doing the following:
1) Set the default storage path for applications to "C:" ("Settings", "Save Locations", "New Apps Will Save To...").
2) Ensured no applications are installed to "D:" ("Settings", "Apps & Features", Filter "D:").
3) Took ownership of the directory/volume ("Properties", "Security", "Advanced").
4) Set the relevant registry keys back to default values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes: "DefaultVolumeKey" = 1, "EnableExternalVolumes" = 1.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\1: "Default" = Null, "Flags" = 2, "MediaId" = Null, "MountPoint" = Null, "Name" = Null, "SISPath" = "C:\Program Files\WindowsApps".
5) Removed unnecessary registry keys (which are created and increment in value — based on the "NextVolumeIndex" DWORD — whenever a new directory/volume is specified):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\2.
6) Performed the equivalent of steps 1-5 through an elevated PowerShell window (using "Set-AppxDefaultVolume", "Get-AppxPackage", "Add-AppxVolume", and "Remove-AppxVolume").
7) Removed/recreated the directory/volume through the recovery command prompt.
8) Removed/recreated the directory/volume through safe mode.
9) Removed/recreated the directory/volume through Linux (using a live CD).
10) Enabled and used the elevated "Administrator" account (by using "net users Administrator /active:yes" in an elevated command prompt).
11) Enabled and used the elevated "SYSTEM" account (by using "psexec -i -s cmd.exe" from System Internals in an elevated command prompt).
12) Assigned a different drive letter (i.e. "D:" became "E:"), even though the volume identifier remained the same.
13) Removed/recreated the partition.
Steps 1-6 (and 12) all resulted in "access is denied" errors. Steps 7-11 all allow the "WindowsApps" directory/volume to be removed and recreated, but not cleanly. If the directory/volume is removed using these methods, and the "WindowsApps" directory is recreated manually (i.e. through File Explorer "explorer.exe"), it will result in system instability (i.e. process not responding). If the directory/volume is recreated using these methods, the permission issues (i.e. "access is denied") return. It seems like a background process/service (which isn't active in safe mode) is locking the directory/volume, and preventing it from being removed/renamed or overwritten. So, the actual file permissions seem irrelevant. The only solution — as ridiculous as it is — is formatting the partition, but the term "solution" is used very loosely.
So, this illogical issue has wasted a significant amount of my time and effort. Why would I say "illogical"? Well, it doesn't make any logical sense as to why an empty and inactive — I repeat, EMPTY and INACTIVE — directory/volume cannot be removed. It could somewhat be justified if the directory/volume was active to prevent tampering, but even then, couldn't the integrity of the package contents simply be verified via checksums? The lengths Microsoft have gone to in order to prevent users modifying these directories/volumes is absurd. It's malware-like.
Now, this is more than just an inconvenience, it's a usability issue. There are legitimate reasons (other than tampering or reverse engineering) why users would need to access the "WindowsApps" directory/volume. The Windows Store allows users to purchase AAA games (such as Rise of the Tomb Raider), which can be quite large in size (in the case of Rise of the Tomb Raider, it's almost 30GB). SSDs have become a necessity for good computing performance (and, as a result, an acceptable user experience), but are still quite expensive based on capacity, which means most users are opting for boot/system disks in the range of 250-500GB. That doesn't stretch very far when a single game can occupy upwards of 10% of the total capacity. So, what happens when a user wants to archive (SSD -> HDD) the application/game (whether it's to increase free space on the SSD or because he/she needs to reinstall Windows)? Should they be expected to download the application/game again? [FYI, the download speeds through the Windows Store are so abysmal, it should be considered a form of torture.] Every notable digital distribution platform (GOG, Origin, Steam, Uplay, etc.) has the ability to backup, restore, and verify the applications/games (or worst case, use junctions), but nope, not Windows Store!
So, either Microsoft hasn't done any usability testing, or they're oblivious to how users would want to utilise a digital distribution platform, or perhaps they just don't care and would prefer to dictate how users should do their computing (considering there are several 3 month old discussions/questions bringing attention to this issue without resolution, this seems likely).
Anyway, it looks like I'll be downgrading back to Windows 7. There is no compelling reason to remain with Windows 10 (apart from DirectX 12, which isn't so appealing now that Vulkan is in the frame), but there are many compelling reasons not to (Convoluted settings — why split them between "Settings" and "Control Panel"? Poor emulation/support for DirectDraw. Privacy concerns. Taking computing control/freedom away from users. The list goes on.).
Continue reading...