Während eines Löschvorgangs ausgeschaltet - Dateisystem dauerhaft verwirrt

Moin Kollegen.

Was ich hier beschreibe, klingt oberflächlich vielleicht 0815, aber die Umstände sind doch sehr kurios, fast lustig:

Nach dem Februar-CU für Windows 11 waren auf einem System plötzlich 65 GB Platz weg (verglichen mit dem imagebackup von einem Tag zuvor) und es wurde eng auf c:
Analyse ergab: im Component Store Bereich "Cache and Temporary Data" (c:\windows\winsxs\temp\inflight) waren, warum auch immer, zeitgleich mit Installation des Updates 350.000(!) Ordner entstanden und eben diese enthielten diese 65 GB.

Das Problem ist für mich nicht ganz neu und es gibt Abhilfe, aber das bewährte Component Store Cleanup lief hier zwar ohne Fehler, brachte aber auf diesem System seltsamerweise nichts und der Platz blieb belegt. Vielleicht schlug dieser Cleanup fehl, da der Platz einfach zu eng war (<5GB Rest). Nun gut, bevor ich eine Sicherung einspiele, gebe ich mir doch mal den Spaß und boote WinPE (=Windows-Setup) und lösche die Inhalte des Ordners von dort aus auf der Kommandozeile (spart viel Zeit, da unter Windows ja zunächst der Besitz übernommen werden muss und auf allen 350.000 Ordnern und x Dateien für den Admin Schreibrechte gesetzt werden müssen - das muss WinPE nicht, da es sich nicht um Rechte schert). Seltsamerweise vergrößerte sich der freie Platz während des Vorgangs nicht. 30 Minuten gewartet, Befehl ist noch immer aktiv - nicht ein Byte gelöscht. VM ausgeschaltet, da sich (unter WinPE!) nicht einmal mehr die Kommandozeile unterbrechen oder schließen ließ.

Bis hierher ist es lediglich seltsam, aber nun kommt's: Nachdem ich dann doch in einem 2. Versuch unter Windows auf der elevated Kommandozeile mit icacls /setowner arbeiten wollte, meldete icacls, dass es auf Tausenden Ordnern den Besitzer nicht ändern kann, während es auf den meisten gelingt. Langsam wird's spooky. Ich nehme also so einen fehlgeschlagenen Ordner und mache die Besitzänderung von Hand im Explorer und es gelingt. Dann nehme ich statt icacls /setowner die takeown.exe und es gelingt ebenfalls - auf allen Ordnern! Sehr seltsam. Sei's drum, die Berechtigungen lassen sich daraufhin auch setzen, alles läuft ohne Fehler durch, nun sollte problemlos gelöscht werden können. Denkste: auf einem kleinen Teil von Ordnern fehlen mir angeblich nach wie vor die Zugriffsrechte. Manuell geprüft - stimmt. Warum icacls bei der versuchten Rechteänderung zuvor keine Fehler gemeldet hat? Weiß der Kuckuck. Egal, die verbleibenden 6 Ordner löschte ich ich dann eben manuell.

Und nun zum besten Teil: der freie Platz auf c: hat sich durch das Löschen lediglich auf 7 GB vergrößert. Wo der Rest hin ist, wüsste ich gerne.
Stirbt die Festplatte? Nein, es ist eine VM und das Plattensystem ist frisch.
Ist das Dateisystem der VM defekt? Nein, auch nicht, chkdsk c: /r meldet KEINE FEHLER.

Ist das geil, oder was? Der Platz ist futsch 58 GB sind im Nirvana verschwunden. Nehme ich Tools wie Treesize oder jdiskreport und starte diese als Systemkonto (höchste Rechte, die man ohne Weiteres erreichen kann) sieht man: Es sind nur 35 GB in Benutzung (so wie es auch zu erwarten ist!), es müssten ergo 65 GB der Platte frei sein, Windows meldet aber nur 7 GB! Auch dism.exe /online /cleanup-image /analyzecomponentstore liest völlig normale Werte aus und der Temp and Cache ist kleiner als 1 GB (vorher waren es ja 65!).

Selbst das Backupprogramm schreibt annährend soviele Daten weg, wie vor dem Update: die Inhalte der Platte sind (nach dem Löschen) also nahezu unverändert! Dennoch sagt auch das Backupprogramm, dass die ge-imagte Platte 100 GB hat und davon 93 belegt sind

Herzlichen Glückwunsch, Sie haben Windows nun komplett verwirrt!

An alle, die das nur quer lesen und die es nun juckt, Tipps loszuwerden: das ist kein größeres Problem. Ich habe ja ein Backup.
Ich schreibe dies hier nieder aus Belustigung und Verwunderung, da ich in 25 Jahren Sysadmin seltenst den Fall hatte, dass Treesize und Windows verschiedener Ansicht waren über den Füllstand einer Festplatte. Wenn, dann war stets das Dateisystem angeknackst und konnte mit chkdsk repariert werden - hier jedoch nicht.

Fragen dazu:
Schonmal erlebt, dass Rechteänderungen auf der Kommandozeile nicht gelingen, aber auf der GUI?
Ist chkdsk neuerdings unfähig?