Deleting Windows folders...
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
-
Put live Linux on a USB, boot, mount Windows share, rm -rf Folder1, Folder2, Folder3 ..., Remove Linux USB, Boot back to windows. Done.
Keep Calm and Carry On
-
NTFS? --Linux
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
Same experience here. I had a laptop with a 2 TB hard disk having four partitions C, D, E, F, 500 GB each with C: having the Win OS. Now, that laptop fell and broke, but luckily nothing happened to the hard disk. I put a cover to this 2 TB hard disk with a USB outlet; essentially making it an external hard drive. It doesn't allow me to delete the Windows folder on that external drive. Same story with Program Files, Program Data.
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
just move the vms to another temp ssd/hdd .. format the old ssd copy it back.. save you trouble
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
We are in the beginning of a mass extinction. - Greta Thunberg
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
Get in trouble shooting windows when booting and remove the folders in CMD Or boot up from a external medium (Hiren's Boot, Bart PE...) and remove the folders from the virtual OS
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
just move the vms to another temp ssd/hdd .. format the old ssd copy it back.. save you trouble
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
That's the way I'd do it - and probably a repartition to dump any bootable stuff as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
NTFS? --Linux
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
Yeah, the partition is NTFS, as I understand it, someone reverse-engineered it all and implemented a Linux driver so NTFS partitions can be mounted/read like any other. NTFS implements ACLs (access control lists) to determine who has access to files/folders. That's part of the file system, so the Linux driver has to follow that in order to be able to access anything. I could be wrong, but that would infer ACLs could be completely bypassed simply by ignoring them. Kinda like movies where someone is prompted for a password, and just types in 'override'. :-) I'll certainly give it a shot, I have other (unrelated) fires to put out this morning...
-
just move the vms to another temp ssd/hdd .. format the old ssd copy it back.. save you trouble
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
Same experience here. I had a laptop with a 2 TB hard disk having four partitions C, D, E, F, 500 GB each with C: having the Win OS. Now, that laptop fell and broke, but luckily nothing happened to the hard disk. I put a cover to this 2 TB hard disk with a USB outlet; essentially making it an external hard drive. It doesn't allow me to delete the Windows folder on that external drive. Same story with Program Files, Program Data.
It took quite a bit of time and patience, but taking ownership of files/folders, I managed to get rid of everything (Program Files, ProgramData) except for a number of Windows subfolders. Some of them just will NOT let me take over. I'll probably just move the VMs folder to another disk and reformat the disk altogether. And merge the boot partition with it, while I'm at it.
-
just move the vms to another temp ssd/hdd .. format the old ssd copy it back.. save you trouble
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
-
Interesting problem. Googling I found the following. First response certainly seems informed. I didn't even know about the commands presented. https://superuser.com/questions/915173/delete-old-windows-program-files-from-second-drive[^]
Yup, I knew about both takeown and icacls (and its predecessor cacls), but there are some (deeply embedded) folders that still don't like to be reassigned. That response on superuser.com might be using a combination of command-line args that I haven't tried - thanks for that.
-
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
Maybe SSD's are "small" so you don't keep anything except the OS on them. I'm in awe when a product lets me install on the drive I choose.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Maybe SSD's are "small" so you don't keep anything except the OS on them. I'm in awe when a product lets me install on the drive I choose.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Interesting problem. Googling I found the following. First response certainly seems informed. I didn't even know about the commands presented. https://superuser.com/questions/915173/delete-old-windows-program-files-from-second-drive[^]
-
That's the way I'd do it - and probably a repartition to dump any bootable stuff as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
diskpart
list disk
select disk #
clean
gpt
exitSoftware Zen:
delete this; -
I have a 2TB SSD that was used to run Windows (on another machine), and Hyper-V...the machine it was hooked up to died months ago, but I did continue to use the SSD in an external USB dock to run the VMs. I have no use for the Windows installation on the drive; I'm not booting from it. So I tried to get rid of everything but the VMs. My god, is it ever an adventure to try to get rid of the existing Program Files, Program Files (x86), ProgramData and Windows folders - even though Windows is NOT running from that disk. Taking ownership of folders, making sure the new ACL applies to child items (files *and* folders), deleting what you can, repeating for whatever Explorer refused to delete the first time around, etc. At this stage, it would've been faster to move the 1.7+ TB worth of VMs on it to another drive, reformat it, and copy the files back. If I was trying to delete folders owned by the OS that is currently running - obviously that's bound to fail. But the OS is on a *data* drive; it *ought* to be easy to take ownership of folders, and delete the whole thing. But nope. I've also been tempted to convert from NTFS to FAT32 (that *will* get rid of all folder permissions), and then back...but that would probably be even slower than moving the data I care about, reformatting, and recopying the files... Anyone's been down that road?
I too got tired of this problem and wrote a little cmd line tool for this.. GitHub - windojitsu/OwnAndResetAcl: Reclaim ownership and control of a directory tree.[^] OwnAndResetAcl A sanity-saving tool for dealing with those pesky "Windows.old" directories Reclaim ownership and control of a directory tree. Recursively takes ownership and resets the ACLs of files, directories and symbolic links. Does NOT follow reparse-points (symlinks or junctions). DOES reclaim ownership and restore access to symlinks and junctions. DOES support traversing/accessing long pathnames. DOES include hidden/system files and directories, and empty directories. DOES NOT modify timestamp or attributes of any files/directories. USE WITH EXTREME CAUTION: Everything in and under the target directory will be owned by the 'Builtin\Administrators' group, and have a DACL which explicitly grants Everyone full-control.
-
I too got tired of this problem and wrote a little cmd line tool for this.. GitHub - windojitsu/OwnAndResetAcl: Reclaim ownership and control of a directory tree.[^] OwnAndResetAcl A sanity-saving tool for dealing with those pesky "Windows.old" directories Reclaim ownership and control of a directory tree. Recursively takes ownership and resets the ACLs of files, directories and symbolic links. Does NOT follow reparse-points (symlinks or junctions). DOES reclaim ownership and restore access to symlinks and junctions. DOES support traversing/accessing long pathnames. DOES include hidden/system files and directories, and empty directories. DOES NOT modify timestamp or attributes of any files/directories. USE WITH EXTREME CAUTION: Everything in and under the target directory will be owned by the 'Builtin\Administrators' group, and have a DACL which explicitly grants Everyone full-control.
Y'know...I had actually given some thought to writing a utility or script to do exactly this, but I figured it ought to get more complex than I might have anticipated from the get-go. Thank you *very* much for the link, I'll be sure to check it out as soon as time permits.
