Hallo zusammen,
ich erstelle seit Jahren Systemimages meiner Windows-Installationen mittels DISM (derzeit mit Version 10.0.10586.0) aus dem Windows Deployment Toolkit. Jetzt ist mir aufgefallen, dass mein System mit Windows 10.0.10586 Pro 64-Bit nach dem Rückspielen des Images erheblich mehr Speicherplatz auf der Festplatte benötigt als zuvor bei der Erstellung des Images. Noch krasser wird der Effekt, wenn ich (nur testweise, ohne praktische Relevanz) sämtliche Daten der Systempartition per Explorer (unter Windows 10 PE auf Basis von Build 10586) auf eine andere Partition kopiere. Das betrifft im Detail die Ordner "ProgramData", "Program Files", "Program Files (x86)" und "Windows", davon wiederum viele (aber nicht alle) Unterordner und Dateien. Dabei existieren auch noch unterschiedliche Angaben zum Speicherverbrauch in Windows. Ich versuche mal, etwas Ordnung in das Chaos zu bringen:
Angaben jeweils ohne $Recycle.bin und System Volume Information. Im Image fehlen außerdem noch ein paar Dateien und Ordner, die offensichtlich nicht relevant sind und von DISM ignoriert werden, deshalb ist dort die Anzahl geringer. Die beiden Pagefile-Dateien, die DISM auch weglässt, sind aber mit drin, die habe ich zwecks Vergleichbarkeit manuell hinzugefügt. Hibernation ist im System deaktiviert und deshalb die entsprechende Datei generell nicht vorhanden. Datenträgerformat jeweils NTFS mit Standard-Clustergröße.
Was für ein Mechanismus greift bei einer Neuinstallation, um den benötigten Festplattenplatz zu reduzieren, der bei der Übertragung eines Images und beim Kopieren der Dateien verloren geht? Datenträgerkomprimierung habe ich nicht aktiviert. Und zumindest die Imagewiederherstellung hat bei Windows 7 diesen Effekt nicht gezeigt, die Explorer-Kopie habe ich damit nicht probiert, da es keinen Anlass dafür gab.
Grüße,
Thomas
EDIT: Jetzt hat es mir trotz "CODE"-Tagging die Tabelle gegenüber der Vorschau doch wieder zerhauen. Ich hoffe, man sieht, worum es geht.
ich erstelle seit Jahren Systemimages meiner Windows-Installationen mittels DISM (derzeit mit Version 10.0.10586.0) aus dem Windows Deployment Toolkit. Jetzt ist mir aufgefallen, dass mein System mit Windows 10.0.10586 Pro 64-Bit nach dem Rückspielen des Images erheblich mehr Speicherplatz auf der Festplatte benötigt als zuvor bei der Erstellung des Images. Noch krasser wird der Effekt, wenn ich (nur testweise, ohne praktische Relevanz) sämtliche Daten der Systempartition per Explorer (unter Windows 10 PE auf Basis von Build 10586) auf eine andere Partition kopiere. Das betrifft im Detail die Ordner "ProgramData", "Program Files", "Program Files (x86)" und "Windows", davon wiederum viele (aber nicht alle) Unterordner und Dateien. Dabei existieren auch noch unterschiedliche Angaben zum Speicherverbrauch in Windows. Ich versuche mal, etwas Ordnung in das Chaos zu bringen:
Code:
Original-Windows-Installation Image wiederhergestellt Kopie über Explorer
Dateizahl: 142.022 142.019 142.022
Ordnerzahl: 29.054 29.050 29.054
Gesamtgröße: 20,9GiB 20,9GiB 20,9GiB
Gesamtgröße auf Datenträger: 15,4GiB 21,0GiB 21,1GiB
Belegter Speicherplatz auf der Partition: 12,4GiB 15,6GiB 21,5GiB
Angaben jeweils ohne $Recycle.bin und System Volume Information. Im Image fehlen außerdem noch ein paar Dateien und Ordner, die offensichtlich nicht relevant sind und von DISM ignoriert werden, deshalb ist dort die Anzahl geringer. Die beiden Pagefile-Dateien, die DISM auch weglässt, sind aber mit drin, die habe ich zwecks Vergleichbarkeit manuell hinzugefügt. Hibernation ist im System deaktiviert und deshalb die entsprechende Datei generell nicht vorhanden. Datenträgerformat jeweils NTFS mit Standard-Clustergröße.
Was für ein Mechanismus greift bei einer Neuinstallation, um den benötigten Festplattenplatz zu reduzieren, der bei der Übertragung eines Images und beim Kopieren der Dateien verloren geht? Datenträgerkomprimierung habe ich nicht aktiviert. Und zumindest die Imagewiederherstellung hat bei Windows 7 diesen Effekt nicht gezeigt, die Explorer-Kopie habe ich damit nicht probiert, da es keinen Anlass dafür gab.
Grüße,
Thomas
EDIT: Jetzt hat es mir trotz "CODE"-Tagging die Tabelle gegenüber der Vorschau doch wieder zerhauen. Ich hoffe, man sieht, worum es geht.