InsideDarkWeb.com

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

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

Super User Asked by Clonkex on November 14, 2021

1 Answers

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

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.

Answered by Clonkex on November 14, 2021

Add your own answers!

Related Questions

A linux program that uses memory

7  Asked on December 4, 2020 by tony_sid

   

Nested virtualization – VirtualBox on Linux in Hyper-V

0  Asked on December 3, 2020 by jonathan-dahlin

     

Dreamweaver CC 2021 bug

0  Asked on November 30, 2020 by l0ot

   

Driver problems with linux/config.h

0  Asked on November 30, 2020 by maxi-kirsch

       

Cloned SSD, how can I clone it again?

1  Asked on November 29, 2020

       

Ask a Question

Get help from others!

© 2021 InsideDarkWeb.com. All rights reserved.