BeiHardlinks und JunctionsIm MSDN-Artikel kann man folgendes lesen:
Ein Hardlink ist die Dateisystemdarstellung einer Datei, bei der mehrere Pfade auf eine einzelne Datei im selben Volume verweisen. Um einen Hardlink zu erstellen, verwenden Sie die Funktion CreateHardLink. Alle Änderungen an dieser Datei sind für Anwendungen, die über die referenzierten Hardlinks darauf zugreifen, sofort sichtbar. Die Verzeichniseintragsgröße und die Attributinformationen werden jedoch nur für den Link aktualisiert, über den die Änderung vorgenommen wurde. Beachten Sie, dass die Attribute der Datei in jedem Hardlink zu dieser Datei widergespiegelt werden und Änderungen an den Attributen dieser Datei auf alle Hardlinks übertragen werden. Wenn Sie beispielsweise das READONLY-Attribut eines Hardlinks zurücksetzen, um diesen bestimmten Hardlink zu löschen, und es mehrere Hardlinks zu der eigentlichen Datei gibt, müssen Sie das READONLY-Bit der Datei von einem der verbleibenden Hardlinks zurücksetzen, um die Datei und alle verbleibenden Hardlinks wieder in den READONLY-Zustand zu versetzen.
Kann jemand den obigen Absatz verstehen?
Ist die Aussage nichtAttribute der Datei werden in jedem Hardlink zu dieser Datei widergespiegeltentspricht der AussageÄnderungen an den Attributen dieser Datei werden auf alle Hardlinks übertragen?
Wie kommtsZurücksetzenREADONLY Bit kannBringen Sie die Datei und alle verbleibenden Hardlinks zurück in den READONLY-Zustand?
BEARBEITEN
Nachdem ich JdeBPs hervorragende Antwort auf diese Frage gelesen habe, habe ich immer noch Zweifel.
$STANDARD_INFORMATIONIch verstehe, dass es für jeden Hardlink, der auf diesen Eintrag verweist, eine Teilkopie des MFT-Eintrags gibt, was der Antwort zufolgewird nicht einmal auf dem neuesten Stand gehalten, es sei denn, ein Hardlink wird umbenannt, erstellt oder zerstört. Was passiert, wenn man die Attribute eines Hardlinks liest? Ich vermute, dass die Kopie dieses Hardlinks $STANDARD_INFORMATIONignoriert wird, da sie möglicherweise nicht den aktuellen Status widerspiegelt und die Attribute direkt aus den Einträgen der MFT gelesen werden $STANDARD_INFORMATION. Außerdem werden während dieses Vorgangs keine Informationen aktualisiert, da es sich nicht um eine der von Ihnen aufgelisteten Operationen handelt. Ist das so?
Wenn man das R-Bit deaktiviert, um das Löschen eines Hardlinks zur Datei zu ermöglichen, muss man (vorausgesetzt, dass dies nicht der letzte Link war) das R-Bit auf irgendeine Weise wieder aktivieren, um die Datei wieder schreibgeschützt zu machen.
Nun, ich verstehe nicht,vorausgesetzt, dass dies nicht der letzte Link warTeil. Ich sehe keinen Unterschied, dass der Link der letzte ist. Es gibt immer noch eine Datei (MFT-Eintrag) selbst und man kann ihre Attribute direkt ändern (nicht über einen Link). Oder ist es so, dass, wenn es eine Datei gibt, ein Link vorhanden ist, was bedeutet, dass es keine Eins-zu-eins-Entsprechung zwischen MFT-Einträgen und Dateien gibt?
Antwort1
Wie grawitygesagt, der zweite „Reset“ ist entweder eine schlechte Schreibweise oder ein regelrechter Fehler.
Ist die Aussage nichtAttribute der Datei werden in jedem Hardlink zu dieser Datei widergespiegeltentspricht der AussageÄnderungen an den Attributen dieser Datei werden auf alle Hardlinks übertragen?
Nein. Der Artikel gibt etwas an, das für seine Zielgruppe vielleicht zu sehr auf Implementierungsdetails eingeht. Unter NTFS kann jeder Eintrag in der MFT null oder mehr$FILE_NAME Attribute. Diese zeichnen das übergeordnete Verzeichnis und den Namen innerhalb dieses Verzeichnisses für jeden Hardlink zur Datei auf. Aber sieAuchDateiattribut-Flags aufzeichnen,wenngleichdiese Flags werden im einzigen $STANDARD_INFORMATIONAttribut des MFT-Eintrags aufgezeichnet. Die Regeln sind ein wenig komplex, aber kurz gesagt $STANDARD_INFORMATIONist das, worauf es ankommt, und die $FILE_NAMEInformationen werden nicht einmal auf dem neuesten Stand gehalten, es sei denn, ein Hardlink wird umbenannt, erstellt oder gelöscht – was eine Änderung der $FILE_NAMEAttribute erfordert, und das gilt auch für den Punkt, an dem die aktuellen Attribut-Flags an die Attribute weitergegeben werden können $FILE_NAME.
Ein Entwickler hat dem technischen Autor, der den MSDN-Artikel geschrieben hat, wahrscheinlich die grausamen Details von NTFS erklärt. Aber für einen Endbenutzer oder sogar einen Anwendungsprogrammierer sind sie eigentlich nicht relevant. Dies sind interne Details der Funktionsweise von NTFS. Aus der Win32-Perspektive hat eine Datei/ein Verzeichnis genaueinsSatz von Attributflags, und wenn man es aktualisiert, aktualisiert man es, wie auch immer das gemacht wird. Wenn man das RBit ausschaltet, um das Löschen eines Hardlinks zur Datei zu ermöglichen, dann (vorausgesetzt, dass dies nicht der letzte Link war) muss man das RBit wieder einschalten, auf welche Weise auch immer, um die Datei wieder schreibgeschützt zu machen.