Bizarres leeres Verzeichnis, das nur mit rmdir /s gelöscht werden kann

Question

Irgendwie bin ich bei einem leeren Verzeichnis gelandet (das ich vor einigen Monaten mit NodeJS als Teil eines von mir ausgeführten Skripts erstellt habe), das nicht mit einem normalen gelöscht werden kann rmdir. Ich kann das Verzeichnis so oft kopieren und einfügen, wie ich möchte, und selbst die Kopien bleiben mit diesem nicht löschbar 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.

Dies geschieht in einer Administrator-Eingabeaufforderung, und ich habe sogar alle Berechtigungen für das Verzeichnis wie folgt festgelegt Full control:

Allem Anschein nach ist das Verzeichnis vollkommen leer. Ich habe im Explorer die Anzeige von versteckten Dateien und Systemdateien aktiviert, sehe jedoch weder Unterverzeichnisse noch Dateien und dir /aauch hier wird nichts angezeigt:

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

Das Ausführen attribim Verzeichnis zeigt nichts:

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

Das andere Merkwürdige ist, dass es mir sagt, Access is deniedwenn ich es versuche, rmdiranstatt The directory is not empty.

Ich habe auch in Betracht gezogen, dass ein Programm einen offenen Handle für das Verzeichnis haben könnte (so unwahrscheinlich das auch ist, nachdem ich es aus dem Original kopiert und eingefügt habe). Nun, nachdem ich alles überprüft hatte, was mir einfiel (LockHunter, Handle-Suche im Process Explorer, Handle-Suche im Resource Monitor und das Handle-Programm von Sysinternals), konnte ich nirgends offene Handles finden.

An diesem Punkt scheint also etwas im Gange zu sein, oder? Was istWirklichDas Seltsame ist, dass wenn ich das mache rmdir /s test(rekursives Löschen), alles problemlos gelöscht wird:

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

Das bedeutet, dass da tatsächlich etwas drin ist test. Was könnte es sein? Ich bin wirklich neugierig, denn nichts von dem, was ich bisher gemacht habe, hat mir etwas Nützliches gezeigt. Ich kann einfach nicht herausfinden, was rmdir testden Fehler in diesem bestimmten Verzeichnis (oder in Kopien davon) verursacht.

Meine offizielle Frage lautet also: Was ist der Grund für dieses bizarre Verhalten?

Answer 1

Dank der hervorragenden Arbeit von @LPChip in den Kommentaren glaube ich, dass ich jetzt meine Antwort habe.

Die Ausführung attribauf dem Ordner selbst ( attrib test) ergab, dass der Ordner über ein schreibgeschütztes Attribut verfügte:

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

Durch Entfernen des Schreibschutzattributs kann der Ordner gelöscht werden:

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

Wenn Sie einen neuen Ordner erstellen und das schreibgeschützte Attribut hinzufügen, wird das Problem exakt reproduziert:

C:\testing>md test2

C:\testing>attrib +r test2

C:\testing>rmdir test2
Access is denied.

Das hat rmdirdas Entfernen des Ordners verhindert, aber zwei Fragen bleiben: 1) Warum funktioniert rmdir /ses, wenn rmdires nicht funktioniert, und 2) warum hat das Ändern des Kontrollkästchens „Schreibgeschützt“ im Eigenschaftendialogfeld keine erkennbare Auswirkung?

Ich habe noch ein bisschen nachgeforscht undgelerntdass der Eigenschaftendialog eines Ordners in Windows es Ihnen nicht erlaubt, das schreibgeschützte Attribut des Ordners selbst festzulegen, sondern nur dessen Inhalt. Ich bin bisher davon ausgegangen, dass der Text„Gilt nur für Dateien im Ordner“meinte, dass die Einstellung des Zustands „gemischt“ nur für den Inhalt gelten würde, „Ein“ jedoch für alles (darüber habe ich nicht nachgedacht), aber eigentlich bedeutet es, dass, wenn Sie es auf den Zustand „Ein“ oder „Aus“ einstellen, der gewählte Zustand nur auf den Inhalt angewendet wird und der Zustand „gemischt“ lediglich bedeutet „alles so lassen, wie es ist“.

Das erklärt das verwirrende Verhalten, das ich im Eigenschaftendialog gesehen habe, aber es erklärt nicht, warum rmdires sagt, Access is deniedaber rmdir /sfunktioniert. Nun... ich weiß nicht. Es könnte eine Sache der Abwärtskompatibilität sein, eine Sache der Unix-Kompatibilität, ein Fehler, eine absichtliche Designentscheidung (using /shat schließlich eine „Sind Sie sicher?“-Eingabeaufforderung). Ich kann keinen Hinweis auf dieses Verhalten finden. Wenn jemand weitere Informationen hat, lassen Sie es mich wissen und ich werde sie der Antwort hinzufügen.