Bizarre empty directory that can only be deleted with rmdir /s

Question

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 . 20/07/2020 04:47 PM .. 20/07/2020 01:25 PM 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: 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:testingtest>dir /a Volume in drive C is Local Disk Volume Serial Number is 8830-C25A Directory of C:testingtest 20/07/2020 01:25 PM . 20/07/2020 01:25 PM .. 0 File(s) 0 bytes 2 Dir(s) 43,123,294,208 bytes free Doing attrib in the dir shows nothing: C:testingtest>attrib File not found - C:testingtest*.* 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 . 20/07/2020 04:58 PM .. 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 · Answer

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:testingtest

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".

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.

Bizarre empty directory that can only be deleted with rmdir /s

One Answer

Add your own answers!

Ask a Question