Datei identifizieren - NTFS File Reference Number

Paul schrieb:
> Hi,
>
> kennt sich hier jemand bestens mit dem NTFS-Dateisystem aus? Ich würde
> gerne wissen, ob die FRN(also diese ID mit 48+16 Bit) eines MFT-Eintrags
> für die eindeutige Identifizierung einer einzelnen Datei/eines Ordners
> auf einer bestimmten NTFS-Partition taugt, oder ob sich diese ID unter
> gewissen Umständen ändern kann?

Also ich denke mal ein File/Verzeichnis kann mehrere davon haben, 
schliesslich hat NTFS/Windows ja seit einer Weile Hardlinks. Hat MS 
natürlich gut versteckt, könnte ja die User verwirren.

Was ist denn dann das "File", die eigentlichen Daten in ihren FS-Blöcken 
oder einer, zwei oder welcher der drei Einträge in der MFT?

Hallo Jasch,

>Was ist denn dann das "File", die eigentlichen Daten in ihren FS-Blöcken
>oder einer, zwei oder welcher der drei Einträge in der MFT?

also um die Nutz-Datenblöcke geht es mir nicht, die können sich bei 
Dateien ja ändern - es bleibt aber dennoch die selbe Datei. Damit 
scheidet ein Hash über den Inhalt oder ähnliches schonmal aus. Mir geht 
es darum, dass ich zu einem beliebigen Zeitpunkt x eine Datei analysiere 
und ab diesem Zeitpunkt die Datei zukünftig im Dateisystem ohne 
permanente Event-Überwachung verfolgen kann, ganz egal ob der Name 
danach geändert wird, oder ob sie verschoben wird oder sich ihr Inhalt 
ändert.

Ehrlich gesagt verstehe ich Deine Frage nicht so ganz, ein Hardlink 
verweist doch letzlich auch nur auf eine bestimmte Datei/ein bestimmtes 
Directory, und dürfte daher in letzter Instanz immer auf einen 
eindeutigen MFT-Eintrag hinauslaufen, oder nicht? Das ließe sich dann 
doch auflösen, sofern Hardlinks als solche gekennzeichnet sind...

Unter Linux gibt es ja glaube ich die iNode-Number. Vermutlich suche ich 
dessen Äquivalent unter Windows - ich bin mir nur nicht sicher, ob z.B. 
bei einer MFT-Defragmentierung die FileID(FRN) geändert wird, oder unter 
welchen Umständen dies möglicherweise noch passiert.

Gruß,
Paul

Paul schrieb:
> Hallo Jasch,
>
>>Was ist denn dann das "File", die eigentlichen Daten in ihren FS-Blöcken
>>oder einer, zwei oder welcher der drei Einträge in der MFT?
>
> also um die Nutz-Datenblöcke geht es mir nicht, die können sich bei
> Dateien ja ändern - es bleibt aber dennoch die selbe Datei.

Nur wenn Du das so definierst, das ist nicht selbstverständlich.

VMS hat z.B. eine Versionsnummer als Bestandteil des Filenamens, jedes 
Ändern der Daten erzeugt dann im Prinzip eine neue Datei, die vorherige 
Version war wiederherstellbar. Ohh, warte mal, das kann Windows ja 
inzwischen auch. Keine Ahnung was das mit den MFT-Einträgen macht.

Dieser Dave Cutler und einige andere der originalen WinNT-Entwickler 
kamen aus Richtung DEC/VMS zu MS... ;-)

> Damit
> scheidet ein Hash über den Inhalt oder ähnliches schonmal aus. Mir geht
> es darum, dass ich zu einem beliebigen Zeitpunkt x eine Datei analysiere
> und ab diesem Zeitpunkt die Datei zukünftig im Dateisystem ohne
> permanente Event-Überwachung verfolgen kann, ganz egal ob der Name
> danach geändert wird, oder ob sie verschoben wird oder sich ihr Inhalt
> ändert.

Hehehe, ab wann nennst Du es denn dann eine "andere" Datei, viel mehr 
gibt es ja nicht? Ist es dieselbe Datei wenn ich die kopiere und das 
Original dann lösche (was übrigens ein Verschieben zwischen Volumes 
tut)? Wenn ja, wieso, wenn nein, wieso nicht?

> Ehrlich gesagt verstehe ich Deine Frage nicht so ganz, ein Hardlink
> verweist doch letzlich auch nur auf eine bestimmte Datei/ein bestimmtes
> Directory, und dürfte daher in letzter Instanz immer auf einen
> eindeutigen MFT-Eintrag hinauslaufen, oder nicht? Das ließe sich dann
> doch auflösen, sofern Hardlinks als solche gekennzeichnet sind...

Hardlinks sind meines Wissens eben nicht als solche gekennzeichnet, alle 
Namen eines Files sind gleichberechtigt.

> Unter Linux gibt es ja glaube ich die iNode-Number. Vermutlich suche ich
> dessen Äquivalent unter Windows - ich bin mir nur nicht sicher, ob z.B.
> bei einer MFT-Defragmentierung die FileID(FRN) geändert wird, oder unter
> welchen Umständen dies möglicherweise noch passiert.

Da würde ich mal ein bisschen in MSDN rumwühlen, da gibt es auch Artikel 
zu NTFS-Interna.

Aber ich habe den Verdacht was Du willst geht nicht ohne weiteres zu 
realisieren - es ist einfach zu ungewöhnlich und auch, wie es so schön 
heisst - ill-defined.

Jasch schrieb:
> Paul schrieb:
[big-snip]
> Da würde ich mal ein bisschen in MSDN rumwühlen, da gibt es auch Artikel
> zu NTFS-Interna.

Also der Tipp war schonmal nicht schlecht wenn ich das so sagen darf.

> Aber ich habe den Verdacht was Du willst geht nicht ohne weiteres zu
> realisieren - es ist einfach zu ungewöhnlich und auch, wie es so schön
> heisst - ill-defined.

An manchen Tagen glaube ich wir sind doch alle in der Matrix und der 
Admin erlaubt sich manchmal einen Scherz.

Da hat ausgerechnet jetzt ein Microsoftie auf seinem Blog "The Old New 
Thing" etwas gepostet was Pauls Problem lösen könnte (Zufall? Wer's 
glaubt! ;-), siehe 
<http://blogs.msdn.com/b/oldnewthing/archive/2011/08/16/10195932.aspx>;, 
speziell die verlinkten Sachen.

Also man kann bei neueren NTFS- und Windows-Versionen (wohl ab Vista, 
Server 2008) einem File eine eindeutige ID verpassen, die ändert sich 
auch nicht durch Umbenennen oder Verschieben solange das auf demselben 
Laufwerk passiert.

Und der Höhepunkt ist man kann das File statt mit seinem Namen auch mit 
dieser ID öffnen - siehe Funktion OpenFileById().

Abgefahrenes Zeug!

Eine weitere Alternative wäre eventuell der Datei per ADS eine GUID zu 
verpassen. Das würde sogar Kopieraktionen und Verschieben über mehrere 
Laufwerke überleben.
http://support.microsoft.com/kb/105763

PS: Dein Link ist etwas kaputt :)
Der hier sollte funktionieren:
http://blogs.msdn.com/b/oldnewthing/archive/2011/08/16/10195932.aspx

Du willst sie als dieselbe Datei erkenenn, auch wenn sie ihren Namen, 
Ort und Inhalt ändert? Was ist dann das Kriterium, aufgrund dessen es 
für dich immer noch dieselbe Datei ist?