Theoriefrage: NTFS, Ordner und wie die Verknüpfung mit Files passiert.
URL: https://www.overclockers.at/windows/theoriefrage_ntfs_ordner_und_wie_die_verknuepfung__165223/page_1 - zur Vollversion wechseln!
semteX schrieb am 03.07.2006 um 12:13
Grüsse.
Geht um ne Klausur von morgen, leider steht die frage so ned im skriptum und google hat uns auch etwas im stich gelassen.
Folgendes ist klar:
Wie werden im MFT die Files gespeichert (resist / non resist)
Wie wird ein Ordner im MFT gespeichert.
Auf den Folien schaut das ganze jetzt dann in etwa so aus:
Für mein verständniss zeigt dieser Ordnereintrag DIREKT auf die Files im Speicher.. (clusteranzahl, startcluster,..) Der müsst doch aber eigentlich nur auf den, zur File gehörenden, eintrag im MFT zeigen oder? Weil woher soll das ding sonst die ganzen Berechtigungsgschichten und ähnliches kennen?
Irendwer ideen, wo mein Denkfehler ist?
Vielen Dank,
semtEX
Indigo schrieb am 04.07.2006 um 13:01
nach meinem verständnis ist der MFT nix anderes wie ein routing table welcher virtuelle cluster auf welchen logischen cluster gemappt wird. mit policies, RSA oder compression hat der MFT afaik noch nix am hut, das geschieht in den verwaltungsebenen drüber.
mat schrieb am 04.07.2006 um 14:02
mal allgemeines:
ntfs behandelt alles wie files. ein file ist einfach nur ein eintrag mit attributen, von filename, filesize, desc, filedata usw. im MFT wird natürlich für jedes file ein eintrag gespeichert (und dadurch auch für jedes verzeichnis, weil ja alles ein file ist 
). jetzt kommt es auf die größe jedes eintrags im mft an. auf der microsoft seite hab ich mal von 2 kb/file gelesen, theoretisch ist es aber zwischen 1 und 4 kb/abhängig von der clustergröße der hd. wenn ein file <= 2 kb hat, dann bleibt es im MFT (resident), hat es mehr dann wird aus ausserhalb des MFT abgelegt (non-resident).
die attribute eines files enthalten auch einen security descriptor (SD), der speichert sicherheitsrelevante informationen für höher gelegende factories (ACLs, ..). das ist der größte unterschied zwischen FAT und NFTS 
da verzeichnisse ja wie files angelegt werden enthalten sie ebenfalls informationen zu sich selbst, wie auch informationen zu verzeichnissen und dateien, die darin liegen. je nachdem wieviele indexdaten das verzeichnis enthält, dürfen auch diese daten im mft liegen. ansonsten werden sie ausgelagert (frag mich jetzt nicht wo genau 
). die verzeichnishierarchie wird dabei intern in einem b-tree abgespeichert (balanced tree).
Für mein verständniss zeigt dieser Ordnereintrag DIREKT auf die Files im Speicher.. (clusteranzahl, startcluster,..) Der müsst doch aber eigentlich nur auf den, zur File gehörenden, eintrag im MFT zeigen oder? Weil woher soll das ding sonst die ganzen Berechtigungsgschichten und ähnliches kennen?
wie oben erwähnt, wenn das file < 2 kb ist, dann zeigt der verzeichniseintrag auf das file, dass sich im mft befindet. ansonsten auf das file im non-resident speicher. im SD attribute stehen dann jeweils die sicherheitsinformationen des files.
wobei ich mir nicht mehr sicher bin, ist was nach der auslagerung eines files noch im mft steht. iirc hab ich auf der microsoftseite vor ein paar jahren gelesen, dass einige (vl auch alle) attribute auch im mft auslesbar sind. das wäre zumindestens von der programmiererseite her logisch, weil dadurch eine schnelle dateiauflistung/verzeichnis möglich ist. von der datenbankdesignseite her ist es allerdings eine katastrophe
semteX schrieb am 04.07.2006 um 14:17
mal allgemeines:
ntfs behandelt alles wie files. ein file ist einfach nur ein eintrag mit attributen, von filename, filesize, desc, filedata usw. im MFT wird natürlich für jedes file ein eintrag gespeichert (und dadurch auch für jedes verzeichnis, weil ja alles ein file ist ). jetzt kommt es auf die größe jedes eintrags im mft an. auf der microsoft seite hab ich mal von 2 kb/file gelesen, theoretisch ist es aber zwischen 1 und 4 kb/abhängig von der clustergröße der hd. wenn ein file <= 2 kb hat, dann bleibt es im MFT (resident), hat es mehr dann wird aus ausserhalb des MFT abgelegt (non-resident).
die attribute eines files enthalten auch einen security descriptor (SD), der speichert sicherheitsrelevante informationen für höher gelegende factories (ACLs, ..). das ist der größte unterschied zwischen FAT und NFTS
da verzeichnisse ja wie files angelegt werden enthalten sie ebenfalls informationen zu sich selbst, wie auch informationen zu verzeichnissen und dateien, die darin liegen. je nachdem wieviele indexdaten das verzeichnis enthält, dürfen auch diese daten im mft liegen. ansonsten werden sie ausgelagert (frag mich jetzt nicht wo genau ). die verzeichnishierarchie wird dabei intern in einem b-tree abgespeichert (balanced tree).
wie oben erwähnt, wenn das file < 2 kb ist, dann zeigt der verzeichniseintrag auf das file, dass sich im mft befindet. ansonsten auf das file im non-resident speicher. im SD attribute stehen dann jeweils die sicherheitsinformationen des files.
wobei ich mir nicht mehr sicher bin, ist was nach der auslagerung eines files noch im mft steht. iirc hab ich auf der microsoftseite vor ein paar jahren gelesen, dass einige (vl auch alle) attribute auch im mft auslesbar sind. das wäre zumindestens von der programmiererseite her logisch, weil dadurch eine schnelle dateiauflistung/verzeichnis möglich ist. von der datenbankdesignseite her ist es allerdings eine katastrophe
Thx das erklärt schonmal einen teil.
Eine etwas weiterführende erklärung hab ich jetzt auch noch im skriptum gefunden... Die zeichnung ist, ganz einfach gesagt, nicht komplett!
In jedem Verzeichniss - MFT Eintrag werden eben auch die Dateinamen, die Startcluter und die Länge gespeichert (entweder eben direkt ober ober einen record, ausgelagert). DAZU kommt noch, dass die ObjectID, also die eindeutige Bezeichnung der Datei (Besteht ja aus FileID + SequenceID, die sich automatisch erhöht) und noch einige andere ausgewählte Attribute mit abgespeichert werden!
So macht das ganze natürlich sinn weil:
Man sieht sofort folgendes: Welche files sind da, wo beginnen sie, wer hat da zuletzt daran herumgebastelt. Sollte speed bringen.
Wenn man nun aber wissen möchte, welche Rechte die File hat, muss über die ObjectID, die ja gleichzeitig der INDEX des Fileeintrags im MFT ist, im MFT selbst nachgschaut werdn, wie es mit den rechten ausschaut...
Klausur selbst hab ich btw "sehr gut" überstanden, danke für eure Hilfe!
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025