Forum Discussion
Spurious folder cannot be deleted on Windows 11: error 0x80004005
I have a spurious folder on a drive that refuses to be deleted (Windows 11 Pro 25H2, all current Windows Updates installed). I have tried everything, and it's still there.
It started when I tried to create a compressed archive using 7-Zip. The archive was to be created in the parent folder of where the files were; so, I added the ..\ prefix to the file name in the 7-Zip dialog window, but I must have inadvertently typed it at the wrong place, with the prefix in the middle of the file name. So, I ended up with a subfolder called R.. (notice the two dots) in the folder where the original files were.
This folder is empty and shows nothing unusual in the "Properties", but when I try to delete it, I get this error message (my Windows is not in English, so I'm translating, and the original English message may be a little different):
An unexpected error is preventing you from deleting this folder. If you continue getting this error, you can use the error code to search for help with this issue.
Error 0x80004005: Unspecified error
As the description implies, this error code is generic and useless. I have searched it, and found a lot of totally different and unrelated issues, but none remotely similar to mine. The same error occurs when I try to delete the parent folder. I can "Try Again" (which only shows the same error message again forever) or cancel.
The folder is on a secondary data SSD (not the system drive), formatted in NTFS and encrypted with BitLocker (like all my drives, by contractual demand from my clients). I have run chkdsk /f unmounting the drive (which the command required), and it found no errors. I have also scheduled a boot-time chkdsk of the drive, but although the countdown appeared, the check itself never happened, and Windows booted right away. Very strange!
Since I suspect that the issue may have something to do with the two dots in the name, I have also tried to rename it. WIndows first shows me the usual warning when you try to change a file extension. After I confirm, it shows the following message (again, a translation):
It was not possible to locate this item.
It is no longer located in [parent_folder_path]. Check the item location and try again.
I took full ownership of the parent folder with total control to all subfolders and explicitly replaced the permissions in all of them. It didn't work. I tried erasing both the rogue folder and its parent folder with a secure-erase utility, and it didn't delete them either.
Other than this stubborn immortal folder, the drive is working normally. I can even create a new folder in the same parent folder as the rogue one, and then I can delete it normally.
What else can I do? Thank you very much for any help.
I have solved the problem in an unorthodox way — and a laborious one, which shouldn't have been necessary: I turned BitLocker off for the drive with the "immortal" folder (that is, I decrypted the drive), then rebooted from a Linux thumb drive, and easily and successfully deleted the folder from there. Then I rebooted back to Windows and restored BitLocker for that drive — which, of course, included generating, saving, and backing up a new recovery key, and deleting the old one at all locations.
The whole process took me over half an hour — too long for what should have been a trivial task of just deleting a folder. Unfortunately, the grandparent folder is important, I back it up regularly, and I wouldn't be able to do so with the spurious subfolder still within it — or at least not without a troublesome reconfiguration. My backup wouldn't be reliable, and other strange errors could occur. This is why I couldn't just let it be there and forget it.
Of course, I will never know what caused this strange behavior and how exactly Windows was reacting to that folder. More importantly, I don't know where the bug was: in 7-Zip, in Windows, or in both. Later I'm going to notify the 7-Zip developers about what happened as well.
1 Reply
I have solved the problem in an unorthodox way — and a laborious one, which shouldn't have been necessary: I turned BitLocker off for the drive with the "immortal" folder (that is, I decrypted the drive), then rebooted from a Linux thumb drive, and easily and successfully deleted the folder from there. Then I rebooted back to Windows and restored BitLocker for that drive — which, of course, included generating, saving, and backing up a new recovery key, and deleting the old one at all locations.
The whole process took me over half an hour — too long for what should have been a trivial task of just deleting a folder. Unfortunately, the grandparent folder is important, I back it up regularly, and I wouldn't be able to do so with the spurious subfolder still within it — or at least not without a troublesome reconfiguration. My backup wouldn't be reliable, and other strange errors could occur. This is why I couldn't just let it be there and forget it.
Of course, I will never know what caused this strange behavior and how exactly Windows was reacting to that folder. More importantly, I don't know where the bug was: in 7-Zip, in Windows, or in both. Later I'm going to notify the 7-Zip developers about what happened as well.