"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Theoriefrage: NTFS, Ordner und wie die Verknüpfung mit Files passiert.

semteX 03.07.2006 - 12:13 1085 3
Posts

semteX

Called it!
Avatar
Registered: Oct 2002
Location: Pre
Posts: 14571
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:

click to enlarge

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
Bearbeitet von semteX am 04.07.2006, 16:12

Indigo

raub_UrhG_vergewaltiger
Avatar
Registered: Mar 2001
Location: gigritzpotschn
Posts: 6690
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

Administrator
Legends never die
Avatar
Registered: Aug 2003
Location: nö
Posts: 25419
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 :p). die verzeichnishierarchie wird dabei intern in einem b-tree abgespeichert (balanced tree).

Zitat
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 :p

semteX

Called it!
Avatar
Registered: Oct 2002
Location: Pre
Posts: 14571
Zitat von mat
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 :p). 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 :p

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!
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz