Cannot Delete Windows.old

[TehSpoopyKitteh]

I updated to Windows 10 1809 and found That could not delete the "Windows.old" folder entirely through Disk Cleanup or Storage Sense. I ended up using command prompt (as administrator) to do it. Please note that this is an absolutely last resort solution. The "App PAckages" usr data folder was what weas causing the issue.

Open Coomand Prompt as Adminstrator and type the following in the order from top to bottom:

cd C:\

rd /s /q \\?\C:\Windows.old

It should look like this if typed in correctly.

The offending file was in the old version of the 'Users/[your user name]/AppData/Local/Packages" folder. It remained indexed as "in use" even though it was not at all in use. It was listed as an existing folder after several restarts.

It should also be noted that whatever drive letter you use as the OS disk, one should probably use that one in stead of C:\
For example, if you use D as the OS drive letter, it will be D:\

[Omega]

This is normal, you have to delete it with disk cleanup.

[TehSpoopyKitteh]

Originally posted by Omega:

This is normal, you have to delete it with disk cleanup.

It wouldn't delete with Disk Cleanup...which is why I used Command Prompt. MS is no longer supporting or developing Disk Cleanup so in order to delete Windows.old, one had to go to Storage Settings for 1809. Trouble is that it still left the folder indexed even though it got deleted. Note I used the Storage Settings option as well.

[Omega]

Originally posted by The Spoopy Kitteh:

Originally posted by Omega:

This is normal, you have to delete it with disk cleanup.

It wouldn't delete with Disk Cleanup...which is why I used Command Prompt. MS is no longer supporting or developing Disk Cleanup so in order to delete Windows.old, one had to go to Storage Settings for 1809. Trouble is that it still left the folder indexed even though it got deleted. Note I used the Storage Settings option as well.

Litterally.. just in this update.. 1809.. Microsoft added another feature to Disk Cleanup.. And it's a part of the Windows OS.

"MS is no longer supporting or developing Disk Cleanup" Bullcrap..

[TehSpoopyKitteh]

Originally posted by Omega:

Originally posted by The Spoopy Kitteh:

It wouldn't delete with Disk Cleanup...which is why I used Command Prompt. MS is no longer supporting or developing Disk Cleanup so in order to delete Windows.old, one had to go to Storage Settings for 1809. Trouble is that it still left the folder indexed even though it got deleted. Note I used the Storage Settings option as well.

Litterally.. just in this update.. 1809.. Microsoft added another feature to Disk Cleanup.. And it's a part of the Windows OS.

"MS is no longer supporting or developing Disk Cleanup" Bullcrap..

The Disk Cleanup utility is Depreciated. This now means you have to go through the Storage settings in Windows 10 to do it.

https://www.ghacks.net/2018/09/14/microsoft-confirms-disk-cleanup-tool-deprecation-in-windows-10/

[Omega]

Originally posted by The Spoopy Kitteh:

Originally posted by Omega:

Litterally.. just in this update.. 1809.. Microsoft added another feature to Disk Cleanup.. And it's a part of the Windows OS.

"MS is no longer supporting or developing Disk Cleanup" Bullcrap..

The Disk Cleanup utility is Depreciated.

https://www.ghacks.net/2018/09/14/microsoft-confirms-disk-cleanup-tool-deprecation-in-windows-10/

Plans, not has.

And you clearly still need it to remove the Windows.old folder right?

[TehSpoopyKitteh]

Originally posted by Omega:

Originally posted by The Spoopy Kitteh:

The Disk Cleanup utility is Depreciated.

https://www.ghacks.net/2018/09/14/microsoft-confirms-disk-cleanup-tool-deprecation-in-windows-10/

Plans, not has.

Neither would delete it at all.

This was the error.
Error 0x80004005: Unspecified error

LocalState..

The issue is that neither Disk Cleanup or the new Storage Sense options fully got rid of The Windows.old folder for the upgrade to Windows 10 1809. It left one of the "AppData\Local\Packages" files untouched...even after restart (like it normally would have done in the first place).

[RGX12]

Originally posted by The Spoopy Kitteh:

Originally posted by Omega:

Plans, not has.

Neither would delete it at all.

This was the error.
Error 0x80004005: Unspecified error

LocalState..

The issue is that neither Disk Cleanup or the new Storage Sense options fully got rid of The Windows.old folder for the upgrade to Windows 10 1809. It left one of the "AppData\Local\Packages" files untouched...even after restart (like it normally would have done in the first place).

If this is still jamming you up, my suggestion would be to try deleting that directory as SYSTEM. Grab yourself PsExec from the SysInternals suite (if you don't have it already), and from an elevated CLI type

psexec –i –s cmd

A second console window will open, this one with full system privileges. Now try killing that Windows.old folder with

rmdir /S /Q <path to Windows.old>

Hope this helps.

EDIT: Nevermind, I see you figured it out in the first post. Nevertheless, wielding the System hammer will work even when operations fail as Administrator, or in rarer cases, as Super Admin (usually due to System-controlled file/folder ACL's). But this would be a last resort, as you said.

[TehSpoopyKitteh]

Originally posted by RGX12:

Originally posted by The Spoopy Kitteh:

Neither would delete it at all.

This was the error.
Error 0x80004005: Unspecified error

LocalState..

The issue is that neither Disk Cleanup or the new Storage Sense options fully got rid of The Windows.old folder for the upgrade to Windows 10 1809. It left one of the "AppData\Local\Packages" files untouched...even after restart (like it normally would have done in the first place).

If this is still jamming you up, my suggestion would be to try deleting that directory as SYSTEM. Grab yourself PsExec from the SysInternals suite (if you don't have it already), and from an elevated CLI type

psexec –i –s cmd

A second console window will open, this one with full system privileges. Now try killing that Windows.old folder with

rmdir /S /Q <path to Windows.old>

Hope this helps.

EDIT: Nevermind, I see you figured it out in the first post. Nevertheless, wielding the System hammer will work even when operations fail as Administrator, or in rarer cases, as Super Admin (usually due to System-controlled file/folder ACL's). But this would be a last resort, as you said.

Indeed. I actually wrote this thread topic as a PSA. I will check your post as the answer so that alternatives are available.

Also, I wouldn’t recommend using the psexec command unless you did this over Telnet.

[RGX12]

Originally posted by The Spoopy Kitteh:

Originally posted by RGX12:

If this is still jamming you up, my suggestion would be to try deleting that directory as SYSTEM. Grab yourself PsExec from the SysInternals suite (if you don't have it already), and from an elevated CLI type

psexec –i –s cmd

A second console window will open, this one with full system privileges. Now try killing that Windows.old folder with

rmdir /S /Q <path to Windows.old>

Hope this helps.

EDIT: Nevermind, I see you figured it out in the first post. Nevertheless, wielding the System hammer will work even when operations fail as Administrator, or in rarer cases, as Super Admin (usually due to System-controlled file/folder ACL's). But this would be a last resort, as you said.

Indeed. I actually wrote this thread topic as a PSA. I will check your post as the answer so that alternatives are available.

Also, I wouldn’t recommend using the psexec command unless you did this over Telnet.

Yep, I noticed that it was meant to be an educational post (and I'm sure many would find it informative) after I did all my typing-- that's what I get for skimming instead of reading in full.

BTW, apropos of your comment, PsExec can directly access remote machines, obviating the need for telnet altogether. But having said that, I find PsExec indispensable for many local duties. For example, getting rid of system-owned Modern UI packages (e.g., to circumvent the infamous Windows restore point rollback fails due to corrupt "Get Microsoft Office" package which plagued Windows 8/8.1 and early versions of Win 10). It was also a critical tool for forcing a proper dismount of removable USB drives which were irrevocably and improperly locked by the SysVol-write-loop bug which was an ugly annoyance on Win XP, 2000, and 7 machines. Last but not least, it comes in handy in a batch file, for when you'd like to delete ALL temporary files automatically upon logoff, a number of which would throw an error due to being locked by the system (unnecessarily locked, because they are no longer being accessed, i.e., orphaned files).
But yes, it's certainly not a tool to be used casually.

[TehSpoopyKitteh]

Originally posted by RGX12:

Originally posted by The Spoopy Kitteh:

Indeed. I actually wrote this thread topic as a PSA. I will check your post as the answer so that alternatives are available.

Also, I wouldn’t recommend using the psexec command unless you did this over Telnet.

Yep, I noticed that it was meant to be an educational post (and I'm sure many would find it informative) after I did all my typing-- that's what I get for skimming instead of reading in full.

BTW, apropos of your comment, PsExec can directly access remote machines, obviating the need for telnet altogether. But having said that, I find PsExec indispensable for many local duties. For example, getting rid of system-owned Modern UI packages (e.g., to circumvent the infamous Windows restore point rollback fails due to corrupt "Get Microsoft Office" package which plagued Windows 8/8.1 and early versions of Win 10). It was also a critical tool for forcing a proper dismount of removable USB drives which were irrevocably and improperly locked by the SysVol-write-loop bug which was an ugly annoyance on Win XP, 2000, and 7 machines. Last but not least, it comes in handy in a batch file, for when you'd like to delete ALL temporary files automatically upon logoff, a number of which would throw an error due to being locked by the system (unnecessarily locked, because they are no longer being accessed, i.e., orphaned files).
But yes, it's certainly not a tool to be used casually.

True.