Ich muss wissen, ob es eine einfache Möglichkeit gibt, nur die Dateien zu erkennen, die auf einem NTFS-Volume gelöscht, geändert oder erstellt wurden.
Ich habe ein Programm für Offsite-Backup in C ++ geschrieben. Nach der ersten Sicherung überprüfe ich das Archivbit jeder Datei, um zu sehen, ob Änderungen vorgenommen wurden, und sichere nur die Dateien, die geändert wurden. Außerdem wird vom VSS-Snapshot gesichert, um Dateisperren zu verhindern.
Dies scheint auf den meisten Dateisystemen gut zu funktionieren, aber bei manchen mit vielen Dateien und Verzeichnissen dauert dieser Vorgang zu lange und die Sicherung dauert oft mehr als einen Tag, um die Sicherung abzuschließen.
Ich habe versucht, das Änderungsjournal zu verwenden, um auf einem NTFS-Volume vorgenommene Änderungen leicht zu erkennen, aber das Änderungsjournal würde viele Datensätze anzeigen, von denen die meisten kleine temporäre Dateien betreffen, die erstellt und zerstört wurden. Außerdem konnte ich den Dateinamen, die Dateireferenznummer und die Referenznummer der Elterndatei angeben, aber ich konnte den vollständigen Dateipfad nicht abrufen. Die Referenznummer der Elterndatei sollte Ihnen den übergeordneten Verzeichnispfad geben.
BEARBEITEN: Dies muss jeden Tag ausgeführt werden, damit zu Beginn jedes Scans nur die Änderungen aufgezeichnet werden, die seit dem letzten Scan stattgefunden haben. Oder zumindest sollte es eine Möglichkeit geben, Änderungen zu sagen, und das und das und das Datum.
Sie können alle Dateien auf einem Volume mit FSCTL_ENUM_USN_DATA auflisten. Dies ist ein schneller Prozess (meine Tests haben sogar auf einer sehr alten Maschine mehr als 6000 Datensätze pro Sekunde ergeben, und 20000+ sind typischer) und enthält nur Dateien, die derzeit existieren.
Die zurückgegebenen Daten enthalten sowohl die Dateiflags als auch die USNs, so dass Sie nach Änderungen suchen können.
Sie müssen weiterhin den vollständigen Pfad für die Dateien ermitteln, indem Sie die übergeordneten IDs mit den Datei-IDs der Verzeichnisse abgleichen. Ein Ansatz wäre, einen Puffer zu verwenden, der groß genug ist, um alle Dateieinträge gleichzeitig zu halten, und die Datensätze zu durchsuchen, um den passenden Elternteil für jede zu sichernde Datei zu finden. Bei großen Datenmengen müssten Sie die Verzeichniseinträge wahrscheinlich in eine effizientere Datenstruktur, möglicherweise eine Hash-Tabelle, aufbereiten.
Alternativ können Sie die Datensätze für die übergeordneten Verzeichnisse nach Bedarf lesen / erneut lesen. Dies wäre weniger effizient, aber die Leistung kann immer noch zufriedenstellend sein, abhängig davon, wie viele Dateien gesichert werden. Windows scheint die von FSCTL_ENUM_USN_DATA zurückgegebenen Daten zwischenzuspeichern.
Dieses Programm durchsucht das C-Volume nach Dateien mit dem Namen test.txt und gibt Informationen über alle gefundenen Dateien sowie über ihre übergeordneten Verzeichnisse zurück.
%Vor%Zusätzliche Hinweise
Wie in den Kommentaren erläutert, müssen Sie möglicherweise MFT_ENUM_DATA durch MFT_ENUM_DATA_V0 bei Windows-Versionen ersetzen, die älter sind als Windows 7. (Dies hängt möglicherweise auch davon ab, welchen Compiler und welches SDK Sie verwenden.)
Ich drucke die 64-Bit-Dateireferenznummern so, als wären sie 32-Bit. Das war nur ein Fehler von mir. Wahrscheinlich im Produktionscode werden Sie sie sowieso nicht drucken, aber FYI.
Das Change Journal ist Ihre beste Wahl. Sie können die Dateireferenznummern verwenden, um Dateierstellungs- / Löschungspaare abzugleichen und somit temporäre Dateien zu ignorieren, ohne sie weiter verarbeiten zu müssen.
Ich denke, Sie müssen die Master File Table scannen, um ParentFileReferenceNumber zu verstehen. Natürlich müssen Sie dabei nur Verzeichnisse verfolgen und eine Datenstruktur verwenden, mit der Sie die Informationen schnell nachschlagen können. Sie müssen die MFT also nur einmal scannen.
Sie können ReadDirectoryChanges und die umgebende Windows-API verwenden.