0

I've somehow ended up with an empty directory (created some months ago with NodeJS as part of a script I ran) that can't be deleted with a regular rmdir. I can copy-paste the directory as many times as I like and even the copies will remain undeletable with rmdir:

C:\testing>dir
 Volume in drive C is Local Disk
 Volume Serial Number is 8830-C25A

 Directory of C:\testing

20/07/2020  04:47 PM    <DIR>          .
20/07/2020  04:47 PM    <DIR>          ..
20/07/2020  01:25 PM    <DIR>          test
               0 File(s)              0 bytes
               3 Dir(s)  43,126,059,008 bytes free

C:\testing>rmdir test
Access is denied.

That's on an administrator cmd prompt, and I even set all the permissions on the directory to Full control:

enter image description here

By all indications, the directory is totally empty; I turned on hidden and system files in Explorer and I see no subdirectories or files, and a dir /a shows nothing either:

C:\testing\test>dir /a
 Volume in drive C is Local Disk
 Volume Serial Number is 8830-C25A

 Directory of C:\testing\test

20/07/2020  01:25 PM    <DIR>          .
20/07/2020  01:25 PM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  43,123,294,208 bytes free

Doing attrib in the dir shows nothing:

C:\testing\test>attrib
File not found - C:\testing\test\*.*

The other odd thing is that it's telling me Access is denied when I try to rmdir rather than The directory is not empty.

I also considered that some program may have an open handle for the directory (as unlikely as that is after copy-pasting from the original). Well, after checking with everything I could think of (LockHunter, Process Explorer handle search, Resource Monitor handle search and Sysinternals' Handle program) I could see no open handles anywhere.

So at this point, it seems like something's up, right? Well what's really strange is that if I do rmdir /s test (recursive delete) it deletes just fine:

C:\testing>rmdir /s test
test, Are you sure (Y/N)? y

C:\testing>dir
 Volume in drive C is Local Disk
 Volume Serial Number is 8830-C25A

 Directory of C:\testing

20/07/2020  04:58 PM    <DIR>          .
20/07/2020  04:58 PM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  43,120,893,952 bytes free

This implies that there's actually something inside test. What could it be? I'm really curious, because nothing I've done so far has shown me anything useful. I simply can't figure out what's causing rmdir test to fail on this particular directory (or any copies of it).

So my official question: What's causing this bizarre behaviour?

Clonkex
  • 1,067
  • 3
  • 13
  • 23
  • 1
    You forgot something in your calculation: A directory is also "undeletable" if a program has a file handle open to it (or on of the file/subdirs in it). In such a case the Windows explorer often shows the "insufficient permissions" error. This can even be caused by a Windows explorer shell extension, hence the Windows Explorer can in such a case be the reason that the folder can not be deleted. – Robert Jul 20 '20 at 07:11
  • 1
    I’m voting to close this question because the problem does not exist anymore and this question is now pure speculation. – LPChip Jul 20 '20 at 07:38
  • @LPChip What? Pure speculation? Speculation about what? I'm asking a concrete question that will have a concrete answer. Just because I know how to work around the problem doesn't mean I don't want to know what caused it in the first place, in particular to avoid it happening again. And besides that, since when are curiosity questions not just as legitimate as someone with an urgent problem? – Clonkex Jul 20 '20 at 22:52
  • @Robert Ah, I forgot to mention in my question, I have checked with every tool in the book, there are no open handles on the directory. Besides which, I would be quite surprised if anything had an open handle on it after copy-pasting the directory. I'll update the question. – Clonkex Jul 20 '20 at 22:53
  • @Clonkex "(Since I've figured out how to delete the directory already, this question is just out of curiosity!)", this implies the problem no longer exists, which means that you cannot test if an answer works or not. Given that this is a Q and A site, we only accept answers that you can prove exists. See the help center to find out more about questions you can ask and what you should avoid asking. So yes, its now speculation because there is no way for you to reproduce the problem anymore and its speculation if that was indeed happening to you. – LPChip Jul 21 '20 at 06:38
  • So the only answer we can give you here is whatever you did as a workaround. – LPChip Jul 21 '20 at 06:39
  • For example, I would first do attrib (no parameters) to get a listing of all files. It probably would find a file with system and hidden attributes, something a simple dir /a will not return and attrib would. Then you probably have to make it visible using attrib, delete it, and then rd will work normally. But again... this is now purely speculation. – LPChip Jul 21 '20 at 06:40
  • @LPChip Please stop telling me it's speculation. I'm not new and I wouldn't have posted it if I didn't have a way to test answers. I still have one of the folders for testing. I'm not asking how to work around the problem, I'm asking what caused this problem. And for the record, `attrib` while in the un-rmdir-able folder `test` tells me `File not found - C:\testing\test\*.*`, which AFAIK means there's nothing there. – Clonkex Jul 21 '20 at 22:51
  • Sorry, no where in your question do you mention you still have ways to test this. Next thing I would do is attrib the folder itself. What happens if you change the attrib of the folder itself to only contain A attribute, not the rest? can you delete it then? – LPChip Jul 21 '20 at 23:39
  • @LPChip `attrib test` says the folder has `R` (read-only, I believe). If I do `attrib -r test` and then `rmdir test` the folder is deleted. So.... wut? Why does a read-only attribute prevent `rmdir test` but not `rmdir /s test`? And why can I not remove the read-only attribute with the properties dialogue (it just comes straight back again)? I also found that creating a new folder and doing `attrib +r test2` perfectly replicates the issue. But either way I think you've answered my question, so if you can think of a way to put that into an answer I'll accept it (or I can do it if you prefer). – Clonkex Jul 22 '20 at 22:53
  • @LPChip Aha! https://superuser.com/a/511691/623023 Apparently Windows is just designed to ignore the read-only attribute when deleting for the most part (presumably to make it easier for users). The GUI also doesn't show the current state of the read-only flags (presumably so it doesn't have to check the read-only flag on every sub-folder) and doesn't apply the flag to the folder itself, only its contents. With that information it now seems like it all boils down to a simple bug (or perhaps backwards compat feature) in `rmdir`. If you don't mind I'd actually like to write up the answer now. – Clonkex Jul 22 '20 at 22:57

1 Answers1

0

Thanks to the excellent work of @LPChip in the comments I believe I now have my answer.

Doing attrib on the folder itself (attrib test) revealed that the folder had a read-only attribute:

C:\testing>attrib test
     R               C:\testing\test

Removing the read-only attribute allows the folder to be deleted:

C:\testing>attrib -r test

C:\testing>rmdir test

C:\testing>dir
 Volume in drive C is Local Disk
 Volume Serial Number is 8830-C25A

 Directory of C:\testing

23/07/2020  09:03 AM    <DIR>          .
23/07/2020  09:03 AM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  43,965,960,192 bytes free

Creating a new folder and adding the read-only attribute replicates the issue exactly:

C:\testing>md test2

C:\testing>attrib +r test2

C:\testing>rmdir test2
Access is denied.

So that's what prevented rmdir from removing the folder, but two questions remain: 1) Why does rmdir /s work when rmdir doesn't, and 2) why does changing the read-only checkbox in the properties dialogue not have any apparent effect?

I did some more digging and learned that the properties dialogue of a folder in Windows doesn't allow you to set the read-only attribute of the folder itself, only its contents. I previously assumed the text "Only applies to files in folder" meant the setting "mixed" state would only apply to contents but "on" would apply to everything (I didn't think that through) but it actually means that if you set it to either the "on" or "off" state it will apply the chosen state to the contents only, and the "mixed" state is just saying "leave everything as it is".

enter image description here

That explains the confusing behaviour I was seeing with the properties dialogue, but it doesn't explain why rmdir says Access is denied but rmdir /s works. Well... I don't know. It could be a backwards-compatibility thing, a Unix-compatibility thing, a bug, an intentional design decision (using /s does have an "are you sure?" prompt, after all). I can't find any reference to this behaviour. If anyone has more information, let me know and I'll add it to the answer.

Clonkex
  • 1,067
  • 3
  • 13
  • 23