NTFS - Größe vom MFT im HexDump

[HuntedHirsch]

Hallo liebe Community!



Im Rahmen von meinem Studium beschäftigen wir uns mit Dateisystemen, sowie deren Aufbau. Nun ist die Frage aufgekommen wieso die Größe des MFT-Eintrags im HexDump eines NTFS-Datenträgerabbilds kodiert ist. Der entsprechende Offset findet sich bei 0x40 und kann entweder positiv oder negativ im Zweierkomplement sein. Im Hexadezimalen ist alles von 0x00 - 0x7F positiv und alles von 0x80 - 0xFF negativ (im Zweierkomplement betrachtet). Möchte man nun die Größe des MFT-Eintrags auslesen, so muss man schauen ob der vorhandene Wert positiv oder negativ ist. Ist er positiv, so ist der gewonnene Wert die Größe des MFT-Eintrags in Clustern. Ist der Wert negativ, so muss mittels Zweierkomplement die Größe berechnet werden. Im Screenshot darunter ist der entsprechende Wert bereits markiert.

Das markierte Byte wird im Dateninspektor als Int8, also Ganzzahl dargestellt. Demnach ist die 0xF6 im Dezimalen eine -10. Jetzt muss man 2^|-10| rechnen um die Größe des MFT-Eintrags in Bytes zu errechnen. Das wäre hier 1024 und umgerechnet in Hex 0x400.

Nun ist die Frage warum man sich dafür entschieden hat bei positiven Werten direkt die Clusteranzahl anzugeben und bei negativen Werten die Größe des MFT-Eintrags in Bytes. (siehe Übersicht im Screenshot)

Vielleicht hat ja wer eine Idee


Vielen Dank & noch mehr Grüße

 

[GrumpyCat]

Vermutlich war die Angabe in Clustern früher üblich, und die Angabe in Bytes wurde nachträglich rangefrickelt, weil jemandem aufgefallen ist, dass "Anzahl Cluster" nicht die allerbeste Idee ist, sowas zu codieren (schon alleine, weil eine Granularität von >=4k für sowas doch arg grob ist).

 

[HuntedHirsch]

Vermutlich war die Angabe in Clustern früher üblich, und die Angabe in Bytes wurde nachträglich rangefrickelt, weil jemandem aufgefallen ist, dass "Anzahl Cluster" nicht die allerbeste Idee ist, sowas zu codieren (schon alleine, weil eine Granularität von >=4k für sowas doch arg grob ist).

Würde Sinn machen, jedoch ist dann die Frage wieso man den positiven Bereich immernoch in Clustern angibt und nicht einfach beides in Bytes... Wenn man schon einmal daran gesessen und einen Teil geändert hat.

 

[gforce4711]

Das markierte Byte wird im Dateninspektor als Int8, also Ganzzahl dargestellt. Demnach ist die 0xF6 im Dezimalen eine -10. Jetzt muss man 2^|-10| rechnen um die Größe des MFT-Eintrags in Bytes zu errechnen. Das wäre hier 1024 und umgerechnet in Hex 0x400.

Nein, du hast das richtige Ergebnis aber falsch gerechnet.
0xF6 ist dezimal -10. Davon das Zweierkomplement ist +10. Also 2^10 = 1024.

Und ist Wikipedia kaputt? NTFS.
Wichtig ist vor allem, wie Dateien abhängig von der Größe - insbesondere wenn sie wachsen - gespeichert werden.
Es gibt auch nicht nur das eine NTFS. Man muß auch schon die Versionshistorie betrachten.

 

[GrumpyCat]

Würde Sinn machen, jedoch ist dann die Frage wieso man den positiven Bereich immernoch in Clustern angibt und nicht einfach beides in Bytes

Abwärtskompatibilität natürlich, dann muss man wegen so einer Kleinigkeit nicht gleich eine neue Major Version ausrollen; man hat weniger Benutzer, die sich "freuen", dass ein Downgrade nicht möglich ist; man braucht kein Filesystem-Migrate-Tool zur neuen Version schreiben. Ist halt ein einfacher fixer Hack.