Windows 11: Ganze Partition in Verzeichnis kopieren

[Nemopuk (nemopuk)]

Walter T. schrieb:
> Schön, dass ihr den Thread übers Wochenende warm gehalten habt.

Man könnte den unteren Teil in einen eigenen Thread abkoppeln, da er 
abgedriftet ist. Aus einer einfachen Aussage die noch zum Thema gehörte, 
ist mittlerweile ein kleines separates Forschungsprojekt geworden.

Hier ist noch einer, vor 13 Jahren:
https://serverfault.com/questions/344766/disk-space-discrepency-between-chkdsk-and-window-explorer

Man findet schon einiges zum Thema, aber weder eine Erklärung noch eine 
Lösung.

Immer wieder werden Bereinigungen und Checks empfohlen und darauf 
hingewiesen, dass die Summe aller Dateigrößen nicht aussagekräftig ist. 
Aber warum Windows GUIs und der dir Befehl danach immer noch viel 
weniger freien Platz anzeigen als chkdsk, das wird weder erklärt noch 
gefixt.

Beim Suchen lande ich immer wieder dort, bzw. Kopien davon:
https://appuals.com/how-to-fix-windows-reporting-wrong-hard-disk-free-space/

Doch auch das führt nicht zur Lösung, und es erklärt nicht die Ursache 
(außer mit der unspezifischen Behauptung, dass es ein Bug seit Windows 7 
sei).

[Nemopuk (nemopuk)]

Entgegen meiner bisherigen Hoffnung ist die Ausgabe von chkdsk wohl 
nicht vertrauenswürdig.

- Der Explorer zeigte 6,5 GB frei an.
- chkdsk zeigte 13 GB als frei an.
- Ich konnte nur 6 GB belegen, das siebte wurde verweigert.
- chkdsk zeigt 7 GB frei an.

[Walter T. (nicolas)]

Nemopuk schrieb:
> Man könnte den unteren Teil in einen eigenen Thread abkoppeln, da er
> abgedriftet ist. Aus einer einfachen Aussage die noch zum Thema gehörte,
> ist mittlerweile ein kleines separates Forschungsprojekt geworden.

Nicht schlimm. Mein Teil ist ja seit Freitag erledigt.

[Alexander (alecxs)]

Erschwerend kommt hinzu dass die Recherche nach zwei Szenarien 
unterschieden werden muss.

Der erste Fall, Summe aller Dateien Größe auf dem Datenträger ist 
größer als der in der Datenträgerverwaltung angezeigte belegte 
Speicherplatz.

Hierfür gibt es plausible Erklärungen:
- Hardlinks werden mehrfach gezählt
- Kompression
- Sparse Dateien die vorgeben größer zu sein als der tatsächlich genutze 
Speicherplatz

Der zweite Fall, der in der Datenträgerverwaltung angezeigte belegte 
Speicherplatz ist größer als die Summe aller Dateien *Größe auf dem 
Datenträger*

Mögliche Erklärungen:
- MFT
- verwaiste/korrupte Dateifragmente belegen Speicherplatz der noch nicht 
als freigegeben markiert wurde
- fehlende Zugriffsberechtigung auf Dateien, Dateigröße kann nicht 
ermittelt werden
- geheime Stealth Dateien in ADS Streams versteckt
- Overhead durch Bitlocker-Verschlüsselung

Hab bestimmt einiges vergessen.

Das alles scheint aber in Deinem Fall nur einen Bruchteil auszumachen. 
Man darf nicht vergessen dass NTFS ein proprietäres Dateisystem ist. 
Linux kann möglicherweise noch nicht so gut damit umgehen wie wir 
glauben.

Oder vielleicht ist es wirklich ein Problem mit der VM.

[Nemopuk (nemopuk)]

Ja Alexander, das hast du gut zusammen gefasst. Sehe ich ganz genau so.

Jetzt wird es spannend:

Ich habe ja eben in
Beitrag "Re: Windows 11: Ganze Partition in Verzeichnis kopieren"
das Laufwerk C unter Windows 10 so voll geschrieben, bis nichts mehr 
geht. Chkdsk zeigt aber noch 7 GB frei an.

Und tatsächlich: Mit Linux konnte ich weitere sieben 1 GB Dateien 
anlegen, die achte war zu viel (2025-09-01_09-44.png). Die achte Datei 
habe ich wieder gelöscht, danach sind etwa 130 MB frei 
(2025-09-01_09-45.png).

Leider startet Windows jetzt nicht mehr, der Anmeldebildschirm erscheint 
nicht (grmpf, aber das war zu erwarten). Also habe ich mit Linux 
schrittweise mehr Platz frei gemacht, bis die Anmeldung wieder 
funktioniert.

Ich habe jetzt laut Linux 7,5 GB frei. Nach der Anmeldung erscheint die 
blaue Fehlermeldung (2025-09-01_10-23.png), habe ich noch nie gesehen. 
Im Startmenü ist die Suchfunktion tot. Der Explorer zeigt 0 Bytes frei 
an, chkdsk sieht aber 6,7 GB als verfügbar (2025-09-01_10-26.png).

Ich lösche ein weiteres GB (dieses mal mit dem Explorer) und starte 
Windows neu. Die blaue Fehlermeldung nach der Anmeldung kommt immer 
noch. Der Explorer zeigt 10 MB frei an (ohne screenshot).

Ich lösche ein weiteres GB mit dem Explorer und starte Windows neu. Die 
blaue Fehlermeldung nach der Anmeldung kommt immer noch. Der Explorer 
zeigt unerwartet viele 4,75 GB frei an (2025-09-01_10-34.png). Meine 
verbleibenden Testdateien sind alle verschwunden!

In der Benachrichtigungsleiste erscheint ein Hinweis, dass ich mit einem 
temporären Profil angemeldet wurde und keinen Zugriff auf Dateien habe. 
Die Suchfunktion im Startmenü ist immer noch tot.

- Chkdsk findet keine Fehler, meldet 7,7 GB als frei 
(2025-09-01_10-37.png).
- *sfc /scannow* findet und repariert beschädigte Dateien.

Ich starte Windows neu, nach der Anmeldung erscheint immer noch die 
blaue Fehlermeldung. Windows ist kaputt.

Ich wechsele zu Linux. Die 1GB Testdateien sind tatsächlich weg. Linux 
meldet 13 GB freien Platz.

Ich schließe daraus:

Windows speichert Daten, die chkdsk nicht sieht (daher als verfügbar 
zählt), ebenso Linux. Mit Windows kann man den Platz nicht beschreiben, 
aber mit Linux. Danach ist Windows kaputt.

Und: chkdsk zeigt den freien Speicherplatz falsch an, der Explorer tut 
es richtig.

[Nemopuk (nemopuk)]

Dass ich Laufwerk C fast komplett voll gemacht habe ging offenbar zu 
weit. Ich will das Experiment nochmal wiederholen, aber reichlich Platz 
frei lassen. Bis gespannt, wie Windows darauf reagiert. Los geht's:

Ich fange mit einer frischen Windows 10 Installation ohne Internet 
Anbindung an. Darin erstelle ich zehn 1 GB Dateien. Der Explorer zeigt 
nur noch 854 MB als frei an, chkdsk meldet 8,8 GB als frei 
(2025-09-01_11-18.png).

Reboot tut gut. Klappt auch, ich kann mich ohne Probleme anmelden. Ich 
fahre Windows ordentlich herunter.

Ich wechsele zu Linux und lege drei weitere 1 GB Dateien an. Laut Linux 
sind noch 6,3 GB frei (2025-09-01_11-33.png).

Zurück zu Windows: Startet nicht mehr. Ich bekomme einen schwarzen 
Bildschirm, kann mich wieder nicht anmelden. Nach einem Kaltstart meldet 
Windows, es sei kaputt (ach!) und muss automatisch repariert werden. 
Nach zwei Wiederholungen kommt die Meldung
> Automatische Reparatur konnte ihren PC nicht reparieren.
Ich habe fertig, Flasche leer.

Offenbar hätte ich die "geheimen" Daten im angeblich freien Bereich 
nicht überschreiben dürfen.

Jetzt dürft ihr mir einen Aluhut aufsetzen!

[Alexander (alecxs)]

Ich bin nach wie vor der Meinung da ist ein Problem mit der 
Virtualisierung. Was nutzt Du überhaupt, Hyper-V, Virtualbox oder 
VMWare? Mir war auch so als ob diese Images Speicherplatz für das RAM 
reservieren (nicht die Auslagerungsdatei, RAM für die VM)

[Nemopuk (nemopuk)]

Alexander schrieb:
> Was nutzt Du überhaupt

QEMU/KVM. Ich werde es bald mit einem alten Laptop ohne VM versuchen. 
Den habe ich mir heute besorgt.

[Nemopuk (nemopuk)]

Alexander schrieb:
> Was nutzt Du überhaupt

QEMU/KVM. Ich werde es bald mit einem alten Laptop ohne VM versuchen. 
Den habe ich mir heute besorgt.

[Harald K. (kirnbichler)]

Alexander schrieb:
> Ich bin nach wie vor der Meinung da ist ein Problem mit der
> Virtualisierung.

Nein, das kann nicht das Problem sein. Völlig egal, wie die 
Virtualisierung funktioniert, der virtualisierte PC sieht ein 
Blockdevice fester Größe, und das beschreibt und liest er.

Daß die Virtualisierung dieses Blockdevice auch in eine dynamisch 
wachsende Datei abbilden kann (deren Gräöße also je nach Füllgrad in der 
VM wächst), spielt hier auch keine Rolle - aus Sicht des virtualisierten 
Betriebssystems ist da ein Blockdevice mit einer fest defierten Anzahl 
von Sektoren. Und die verwaltet es.

[Nemopuk (nemopuk)]

Alexander schrieb:
> Ich bin nach wie vor der Meinung da ist ein Problem mit der
> Virtualisierung.

Nemopuk schrieb:
> Ich werde es bald mit einem alten Laptop ohne VM versuchen.

Hat eine Weile gedauert, weil mein USB Stick kaputt gegangen ist.

Die SSD hat 120 GB.
Der Explorer meldet 97 GB frei.
Chkdsk ebenfalls).

Der Laptop läuft heiß und super lahm, weil er Treiber braucht (das bin 
ich bei diesem Modell so gewohnt).
Also habe ich Internet aktiviert und die Updates durch laufen lassen.
Dann noch ein paar Treiber vom Hersteller manuell installiert.

Die SSD hat immer noch 120 GB :-)
Der Explorer meldet 86 GB frei.
Chkdsk ebenfalls.

Also dieser Laptop nicht betroffen.

-----
Der Laptop meiner Frau wurde vor ein paar Wochen von Windows 10 auf 11 
aktualisiert.

Die SSD hat 240 GB.
Der Explorer meldet 160 GB frei.
Chkdsk meldet mehr: 166 GB (174087660 kB) frei.

Er ist also betroffen. Auf diesem Rechner darf ich keine Experimente 
durchführen.

-----
Ich habe auch Oracle VirtualBox versucht, aber das habe ich nicht ans 
Laufen bekommen. Vielleicht kollidiert es mit QEMU/KVM.

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> Ich wechsele zu Linux und lege drei weitere 1 GB Dateien an. Laut Linux
> sind noch 6,3 GB frei (2025-09-01_11-33.png).
>
> Zurück zu Windows: Startet nicht mehr.

Spannend wäre gewesen, was passiert wäre, wenn du die drei zusätzlichen 
Dateien einfach auch noch unter Windows geschrieben hättest...

Wetten, dass es dann auch nach dem Reboot noch gestartet wäre oder 
alternativ bereits beim Schreiben eine Fehlermeldung gekommen wäre?

Merke: Es war noch nie eine gute Idee, ein Filesystem bis an den Rand 
vollzuschreiben. Das gilt übrigens auch bei den unter Linux üblichen FS, 
nicht nur bei NTFS.

Es gilt um so mehr, je mehr Spielereien, ooops... Features ein FS 
anbietet.

[Nemopuk (nemopuk)]

Ob S. schrieb:
> Spannend wäre gewesen, was passiert wäre, wenn du die drei zusätzlichen
> Dateien einfach auch noch unter Windows geschrieben hättest...

Das geht nicht. Habe ich versucht, bricht mit "disk full" ab. Windows 
schützt sich.

> Es war noch nie eine gute Idee, ein Filesystem bis an den
> Rand vollzuschreiben

Bei Windows wird empfohlen, 25% frei zu halten. Das soll nicht nur der 
Stabilität gut tun, sondern auch der Lebensdauer der SSD.

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> Das geht nicht. Habe ich versucht, bricht mit "disk full" ab.

Dacht' ich's doch.

> Windows
> schützt sich.

Der Filesystemtreiber schützt sein Filesystem. U.a. dadurch, das er 
immer genug Platz frei hält, so dass er auch die exotischste denkbare 
Anforderung zur Strukturänderung noch in das Log (AKA: Jounal) schreiben 
kann.

ntfs-3g sieht das etwas entspannter, weil es einige exotische 
NTFS-Features einfach mal nicht unterstützt. Deswegen hält es deutlich 
weniger Platz in Reserve für nötig.

Sprich: wenn du die drei Dateien unter Linux auch gleich wieder gelöscht 
hättest, wäre überhaupt nix Schlimmes passiert. Oder anders ausgedrückt: 
es gibt keine versteckten Windows-Daten. Die wären nämlich auch dann weg 
gewesen.

Das Problem war wirklich nur, dass der Windows-NTFS-Treiber nicht mehr 
genug Platz gesehen hat, um beliebige Schreibvorgänge zuverlässig 
durchzuführen und deshalb konsequenterweise überhaupt keine mehr 
erlaubt, auch keine einfachen mehr, die eigentlich viel weniger Platz 
benötigen würden. Ohne Schreibzugriff auf die Systemplatte mag Windows 
aber nicht booten.

Ich könnte mir übrigens gut vorstellen, dass es nach dem 
fehlgeschlagenen Boot auch genügt hätte, unter Linux diese drei Dateien 
wieder zu löschen, um alles wieder in's Lot zu bringen. Aber nach der 
Anwendung der Windows-Reparaturfunktionen geht das vermutlich dann nicht 
mehr.

[Nemopuk (nemopuk)]

Ob S. schrieb:
> Sprich: wenn du die drei Dateien unter Linux auch gleich wieder gelöscht
> hättest, wäre überhaupt nix Schlimmes passiert.

Das habe ich durch gespielt. Windows ist danach trotzdem kaputt.

> Ich könnte mir übrigens gut vorstellen, dass es nach dem
> fehlgeschlagenen Boot auch genügt hätte, unter Linux diese
> drei Dateien wieder zu löschen

Auch das habe ich probiert (sogar vorher). Windows bleibt danach 
trotzdem kaputt. Ich habe noch lange nicht jeden Versuch hier einzeln 
berichtet. Immerhin bin seit 3 Tagen durchgehen an dem Thema dran.

Man darf in die letzten reservierten GB wirklich nicht hinein schreiben. 
Wenn du einen Rechner hast, der betroffen ist, kannst du es diesem 
probieren. Ich habe es mehr als 6 mal wiederholt, Windows war immer 
kaputt. Egal wann und womit ich die Dateien wieder gelöscht habe.

> Das Problem war wirklich nur, dass der Windows-NTFS-Treiber nicht
> mehr menug Platz gesehen hat, um beliebige Schreibvorgänge zuverlässig
> durchzuführen und deshalb konsequenterweise überhaupt keine mehr
> erlaubt

Das passt nicht zu meiner Beobachtung, dass Windows diesen "verborgenen 
Bereich" nicht anlegt, wenn Laufwerk C nur 16 oder 20 GB klein ist. 
Trotzdem funktioniert es damit tadellos.

> Aber nach der Anwendung der Windows-Reparaturfunktionen geht das
> vermutlich dann nicht mehr.

Ich frage mich, ob die Windows-Reparatur jemals funktioniert hat. Bei 
mir jedenfalls noch nie. Ich habe eher den Eindruck, dass sie es noch 
schlimmer macht. Jedenfalls habe ich natürlich nach jedem Versuch immer 
wieder eine neue VM aufgesetzt und frisch installiert.

Ich habe zu dem Thema eine Webseite erstellt. Die kann ich besser mit 
neuen Erkenntnissen aktualisieren - falls da noch was kommt. Ich bin mit 
meinem Latein nämlich vorläufig am Ende.

http://stefanfrings.de/ntfs_geheimnis/index.html

[Alexander (alecxs)]

Nemopuk schrieb:
> Also dieser Laptop nicht betroffen.

Nemopuk schrieb:
> Der Laptop meiner Frau wurde vor ein paar Wochen von Windows 10 auf 11
> aktualisiert

Gibt's sonst noch Unterschiede BIOS/UEFI, MBR/GPT, Bitlocker?

[Nemopuk (nemopuk)]

Alexander schrieb:
> Gibt's sonst noch Unterschiede BIOS/UEFI, MBR/GPT, Bitlocker?

Beide haben UEFI, GPT und kein Bitlocker und eine NVMe.

Die VM mit Problem emulieren ein SATA Laufwerk (eine andere Wahl habe 
ich da nicht).

[Harald K. (kirnbichler)]

Nemopuk schrieb:
> Die VM mit Problem emulieren ein SATA Laufwerk

Und trotzdem: Daran liegt es nicht.

[Alexander (alecxs)]

Kann man sich die MFT genauer ansehen? Ich weiß noch aus Windows 2000 
Zeiten, als NTFS Support noch hochgradig experimentell war, hatte sich 
ein Backup als unzureichend erwiesen das ich mit Linux erstellt hatte. 
Grund war, dass die MFT bei mir größer war als Standard und das Tool die 
einfach nicht komplett gesichert hatte.

Google sagt NTFSInfo oder MFTECmd.

> NTFS reserviert 12,5 Prozent des Volumens für die ausschließliche
> Nutzung des MFT

https://learn.microsoft.com/de-de/troubleshoot/windows-server/backup-and-storage/ntfs-reserves-space-for-mft

[Nemopuk (nemopuk)]

Harald K. schrieb:
>> Die VM mit Problem emulieren ein SATA Laufwerk
> Und trotzdem: Daran liegt es nicht.

Würde mich auch sehr wundern.

> Kann man sich die MFT genauer ansehen?

Wozu? Deren Größe wird offensichtlich sowohl vom Explorer als von chkdsk 
berücksichtigt. Laut Microsofts Doku ist sie in dem Posten "vom System 
benutzt" enthalten.

> Google sagt NTFSInfo oder MFTECmd.

Gibt es beides nicht in Windows. Ich habe auch keine Lust, noch mehr 
Fremdprogramme auszuprobieren. Jedes zeigt was anderes an, am Ende weiß 
man gar nicht mehr, welchem man vertrauen soll.

[Alexander (alecxs)]

Nemopuk schrieb:
> Wozu? Deren Größe wird offensichtlich sowohl vom Explorer als von chkdsk
> berücksichtigt.

Vielleicht aber auch nur die Standardgröße, denn es sind jedenfalls 
keine 12,5 %

[Nemopuk (nemopuk)]

Die Größe der MFT wird von
> fsutil fsinfo ntfsinfo c:
angezeigt.

Interessanter finde ich diese beiden Zeilen in der AUsgabe:
> Reservierte Cluster insgesamt :   1.719.311  (  6,6 GB)
> Reserviert für Speicherreserve :  1.697.154  (  6,5 GB)
Die Größe kommt mir verdächtig vor.

Habe dazu dies gefunden:
Die MFT liegt ziemlich am Anfang der Partition, gefolgt von 12,5% 
reserviertem Bereich, der möglichst lange nicht mit Dateien belegt wird. 
Erst wenn die ganze Partition voll ist, wird in diesen Bereich 
geschrieben.

Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu 
tun haben könnte. Das schaue ich mir morgen genauer an.

Mehr dazu in
https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/ntfs-reserves-space-for-mft

Und dann habe ich noch das gefunden, könnte auch relevant sein:
https://windowsforum.com/threads/disable-reserved-storage-in-windows-10-11-to-reclaim-3-7-gb-safely.378675/#google_vignette

[Alexander (alecxs)]

Nemopuk schrieb:
> 
https://windowsforum.com/threads/disable-reserved-storage-in-windows-10-11-to-reclaim-3-7-gb-safely.378675

Was allerdings für SSD auch Sinn macht. Die brauchen jede Menge Platz 
zum umschaufeln, werden unerträglich langsam wenn die voll sind.

[Nemopuk (nemopuk)]

Opa führt Selbstgespräche :-)

Nemopuk schrieb:
> Der Explorer meldet 86 GB frei.
> Chkdsk ebenfalls.
> Also dieser Laptop nicht betroffen.

Inzwischen hat sich die Situation auf diesem frisch installierten Laptop 
geändert.

Der Explorer meldet 84,8 GB frei.
Chkdsk meldet 86 GB frei.

Was habe ich gemacht? Den Edge Browser benutzt, um nach Informationen zu 
suchen.

Nemopuk schrieb:
> Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu
> tun haben könnte.

Hat er nicht. Die Größe von "Reserviert für Speicherreserve" entspricht 
nicht der Differenz zwischen dem verfügbaren Speicher im Explorer 
versus chkdsk. Ich habe das auf 3 Computern kontrolliert (einer davon 
eine VM).

Nemopuk schrieb:
> Und dann habe ich noch das gefunden, könnte auch relevant sein:
> 
https://windowsforum.com/threads/disable-reserved-storage-in-windows-10-11-to-reclaim-3-7-gb-safely.378675/#google_vignette

Noch ein Artikel dazu:
Opa führt Selbstgespräche :-)

Nemopuk schrieb:
> Der Explorer meldet 86 GB frei.
> Chkdsk ebenfalls.
> Also dieser Laptop nicht betroffen.

Inzwischen hat sich die Situation auf diesem frisch installierten Laptop 
geändert.

Der Explorer meldet 84,8 GB frei.
Chkdsk meldet 86 GB frei.

Was habe ich gemacht? Den Edge Browser benutzt, um nach Informationen zu 
suchen.

Nemopuk schrieb:
> Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu
> tun haben könnte.

Hat er nicht. Die Größe von "Reserviert für Speicherreserve" entspricht 
nicht der Differenz zwischen dem verfügbaren Speicher im Explorer 
versus chkdsk. Ich habe das auf 3 Computern kontrolliert (einer davon 
eine VM).

Nemopuk schrieb:
> Und dann habe ich noch das gefunden, könnte auch relevant sein:
> 
https://windowsforum.com/threads/disable-reserved-storage-in-windows-10-11-to-reclaim-3-7-gb-safely.378675/#google_vignette

Die Zahlen lassen sich dennoch nicht miteinander verrechnen.

Das ist es auch nicht. Die Zahlen lassen sich nicht miteinander 
verrechnen, wie man auf dem Screenshot meiner VM sieht.

Zum Reservierten Speicher habe ich noch diese Erklärung gefunden:
https://support.microsoft.com/de-de/windows/speichereinstellungen-in-windows-5bc98443-0711-8038-4621-6a18ddc904f2

Bringt mich jetzt auch nicht weiter, aber ich finde es in dem 
Zusammenhang interessant.

[Alexander (alecxs)]

Du gehst nicht systematisch genug vor. Ich würde ein kleines Script 
schreiben dass erstmal alle Hardlinks und Streams rechnet. Und wieviel 
für die MFT tatsächlich reserviert ist muss man auch irgendwie 
rauskriegen. Die Sysinternals von Mark Russinovich sind so gut das M$ 
sie irgendwann übernommen hat. Vielleicht ist da das richtige Werkzeug 
dabei.

Eine Diskrepanz zwischen du / df gibt es übrigens auch auf jedem ext4 
Dateisystem. Dort wird Speicherplatz reserviert für die inodes. 
Gelöschte Dateien die noch von irgendeinem Programm offen gehalten 
werden bleiben auch physisch vorhanden, der Speicherplatz wird erst nach 
einem mount frei.

Dateisysteme haben einen Overhead.

[Nemopuk (nemopuk)]

Jetzt habe ich in der VM diesen reservierten Speicher in der Powershell 
deaktiviert:
> Set-WindowsReservedStorageState -State Disabled

Der Explorer zeigt nun schlagartig 3,5 GB mehr verfügbaren Platz an 
(soviel war vorher reserviert).

Der von chkdsk als verfügbar gemeldete Platz ist unverändert geblieben.

Ich habe jetzt folgende Zahlen:

Explorer meldet 29568655360 27,5 GB frei.
Chkdsk meldet 27452856 kB (=26,7 GB?) verfügbar.

Die Angabe in Klammern stammt von mir. Dazu habe ich die Zahl zweimal 
durch 1024 geteilt. Wenn ich sie stattdessen zweimal durch 1000 teile, 
passen sie!

----------
Zum Vergleich schaue ich mir die Lage auf dem Laptop an. Dort ist der 
Reservierte Speicher größer, fast 7 GB. Ich deaktiviere ihn und 
kontrolliere das Ergebnis:

Explorer meldet 98297266176 91,5 GB frei.
Chkdsk meldet 91225276 kB (=87,0 GB?) verfügbar.

Auch hier stimmen die Zahlen nicht, aber wenn ich zweimal durch 1000 
teile, stimmt es!

Offenbar rechnet Windows komisch. Ein Kilobyte sind 1024 Bytes, aber ein 
Gigabyte sind 1000*1000 Kilobytes. Ich finde das vollkommen unlogisch. 
Bin ich dumm?

Wie dem auch sei, die Zahlen passen so. Der mysteriöse Verlust von 
Speicherplatz ist geklärt.

[Nemopuk (nemopuk)]

Alexander schrieb:
> Dateisysteme haben einen Overhead.

Das ist schon klar. Es ging mir die ganze Zeit aber darum, dass chkdsk 
und Explorer unterschiedlcih viel verfügbaren Platz anzeigen. Womit der 
Platz belegt ist und wie viel Overhead für was auch immer da drin ist, 
war mir egal.

Für mich war es ein Unding, dass der Explorer viel weniger freien Platz 
anzeigte, als chkdsk und Linux. Das ist ja nun geklärt.

Ich mache gerade noch einen Gegentest mit einer kleinen 16 GB VM. Ich 
erwarte, dass Windows dort keinen Platz reserviert. Das würde meine 
vorherigen Beobachtungen bestätigen, dass bei so einer kleinen VM die 
Angaben von Explorer und chkdsk immer (ungefähr) überein stimmten.

Und danach will ich noch weiter Untersuchen, warum Schreibzugriffe unter 
Linux ab einer gewissen Schwelle das Windows kaputt gemacht haben.

[Nemopuk (nemopuk)]

Gegentest auf einer kleinen VM mit nur 16 GB Laufwerk.

Windows hat keinen Speicherplatz reserviert (der wäre links oben 
zwischen "Systemdateien" und "Virtueller Speicher" angezeigt worden).
Explorer meldet 4,51 GB frei.
Chkdsk meldet 4706000 kB verfügbar.

Wenn ich den Wert von chkdsk zweimal durch 1024 teile. komme ich auf 
4,49 GB. Das wirkt einigermaßen stimmig.

Wenn ich nach meiner neuen Erkenntnis den Wert von chkdsk zweimal durch 
1000 teile komme ich auf 4,71 GB. So gerechnet fehlen mir wieder 200 MB.

Ich muss aber dazu sagen, dass mich so geringe Differenzen nicht 
triggern. Mir fallen einige Gründe ein, die zu kleinen Abweichungen 
führen können:

- Andere Umrechnung der Einheiten
- Messungen der Tools nicht exakt zum gleichen Zeitpunkt
- Verzögertes Schreiben

Das ist hier aber eine ganz andere Hausnummer, als die zuvor beobachtete 
Differenz von ca. 7 Gigabytes. Ich lasse es mal dabei beruhen.

Die Differenz ist damit für mich ausreichend geklärt. Sie lag am 
reservierten Speicherbereich, den Windows nach der Installation (wenn 
möglich) automatisch anlegt. Betroffene Rechner haben ihn, andere nicht. 
Man kann ihn manuell deaktivieren.

Was mich jetzt noch interessiert, sind die Schreibzugriffe von Linux, 
die das Windows kaputt gemacht haben.

[Alexander (alecxs)]

Nemopuk schrieb:
> Offenbar rechnet Windows komisch.

Zumindest passen die Einheiten dann wieder.

[Harald K. (kirnbichler)]

Nemopuk schrieb:
> Die Angabe in Klammern stammt von mir. Dazu habe ich die Zahl zweimal
> durch 1024 geteilt. Wenn ich sie stattdessen zweimal durch 1000 teile,
> passen sie!

1 kB = 10^3 Byte, 1 MB = 10^6 Byte, 1 GB = 10^9 Byte

Das sind normale SI-Präfixe. 1 kg sind auch 1000g. Erstaunlicherweise 
stellt das niemand in Frage.

Die Binärpräfixe mögen für manche Leute immer noch schwer zu ertragen 
sein, aber sie zu verwenden ist offensichtlich sinnvoll.

1 kiB = 2^10 Byte, 1 MiB = 2^20 Byte, 1 GiB = 2^30 Byte

Historisch gewachsen ist leider die Verwendung von binären Werten mit 
den falschen, dezimalen Präfixen. Manch einer meint, dies mit einem 
großgeschiebenen "K" angeben zu können, nur sehe ich in MB kein "k", 
egal, ob groß oder kleingeschrieben.

[Nemopuk (nemopuk)]

Harald K. schrieb:
> Historisch gewachsen

und ziemlich verwirrend. Danke für deine Erklärung.

[Nemopuk (nemopuk)]

Auf einer kleinen VM (Windows 10, 16 GB, ohne reservierten Speicher, 
ohne Internet):

1) Windows installiert, dann unter Linux die Partition komplett voll 
geschrieben und die Datei wieder gelöscht.
Windows funktioniert.

2) Partition wieder mit Linux voll geschrieben und die Datei dann so 
weit gekürzt, dass 2,5 GB frei sind.
Windows funktioniert.

------
Auf einer großen VM (Windows 10, 40 GB mit 7,6 GB reserviertem Speicher, 
ohne Internet):

3) Windows installiert, dann unter Linux die Partition komplett voll 
geschrieben und die Datei wieder gelöscht.
Windows funktioniert noch.

Test 3 wiederholt: Windows funktioniert noch

4) Partition wieder mit Linux voll geschrieben und die Datei dann so 
weit gekürzt, dass 2,7 GB frei sind.
Windows ist kaputt.

Test 4 wiederholt: Windows ist wieder kaputt

5) Windows installiert, Partition mit Linux voll geschrieben und die 
Datei dann so weit gekürzt, dass 6 GB frei sind.
Windows ist kaputt.

6) Windows installiert, Partition mit Linux voll geschrieben und die 
Datei dann so weit gekürzt, dass 7 GB frei sind.
Windows ist kaputt.

7) Windows installiert, Partition mit Linux voll geschrieben und die 
Datei dann so weit gekürzt, dass 8 GB frei sind.
Windows funktioniert.

Test 7 wiederholt: Windows funktioniert.

------
Auf einer großen VM (Windows 11, 40 GB mit 7,03 GB reserviertem 
Speicher):

8) Windows installiert, Netzwerk deaktiviert, Bitlocker entfernt.
Partition mit Linux voll geschrieben und die Datei dann so weit gekürzt, 
dass 8 GB frei sind.
Windows funktioniert.

9) Noch eine 2 GB Datei hinzugefügt (bin damit im reservierten Bereich).
Windows ist kaputt.

------
Daraus ziehe ich drei Schlüsse:

- Ohne reservierten Bereich sind 2,5 GB freier Platz ausreichend, damit 
Windows starten kann (vielleicht geht auch weniger).
- Man darf den reservierten Bereich außerhalb von Windows ruhig komplett 
überschreiben.
- Vor dem nächsten Start von Windows muss der reservierte Bereich aber 
wieder frei gemacht werden, sonst geht Windows kaputt.

Also ziemlich unspektakulär. Keine geheimen Daten, kein Aluhut.

------
Ob S. schrieb:
> Ich könnte mir übrigens gut vorstellen, dass es nach dem
> fehlgeschlagenen Boot auch genügt hätte, unter Linux diese drei Dateien
> wieder zu löschen, um alles wieder in's Lot zu bringen

Ich hatte dir gestern geantwortet, dass ich genau das ohne Erfolg 
versucht hatte. Die heutige Testreihe zeigt, dass das nicht sein kann. 
Ich kann mir das nur so erklären, das ich gestern versehentlich zu 
wenige der 1GB Dateien gelöscht hatte.

[Nemopuk (nemopuk)]

Ich glaube, das Thema ist hiermit abgeschlossen. Wer später nach 
Erklärungen sucht, wird vielleicht diese Diskussion finden. Deswegen 
platziere ich zum Abschluss nochmal den Link zu Webseite, wo ich die 
Ergebnisse zusammen gefasst habe.

http://stefanfrings.de/ntfs_geheimnis/index.html

[Walter T. (nicolas)]

In Deiner Zusammenfassung fehlt noch der Nutzer "TrustedInstaller", der 
von den Berechtigungen über dem Administrator steht. Dateien, die nur er 
sehen darf, werden auch mit 0 Bytes angezeigt.

(Beispiel: Der über 10 GB große Ordner "C:\Program Files\WindowsApps")