dwReserved1 nutzen?

[e-gon]

Danke himitsu,

ob die Daten auf einer Synology-DS liegen muss ich erst noch herausfinden. Bezüglich Tags in Video- und Audioformaten fand ich tatsächlich einige Beispiele. Das Problem dabei ist, dass das Schreiben/Auslesen nicht überall gleich funktioniert und ich somit für jeden Dateityp etwas programmieren müsste.

Zitat von Redeemer:

Du hast glaube ich keine Ahnung, was du schreibst.
Du willst Daten suchen, sprich lesen. Wieso willst du in einer Datenstruktur Daten schreiben, die eine Anforderung zum Lesen beschreibt? Beides für sich genommen (Lesen und Anforderung) ist bereits maximal falsch: Du kannst keine Daten lesen, die nie geschrieben wurden, und du kannst in einer im Arbeitsspeicher abgelegten Anforderung nichts dauerhaft speichern.
Das ist exakt so, als würdest du einen leeren Notizblock nehmen, "Zeig mir die Bild-Zeitung von heute!" sagen und dich dann wundern, dass auf dem Notizblock immer noch nichts steht.

Ich verstehe die Kritik nicht so richtig. Die Variablen dwReserved0 und dwReserved1 sind in der Datenstruktur von WIN32_FIND_DATA hinterlegt. Es wird also dafür Speicherplatz reserviert und auch im Dateisystem zusammen mit CreationTime, LastAccessTime, LastWriteTime, dwFileAttributes auf der Festplatte abgelegt. Ansonsten wären die vorbereiteten, zukünftig vielleicht benutzten Variablen ja unsinnig.

Ob dwReserved0 und dwReserved1 jedoch beim Umbenennen und/oder verschieben mitgeführt werden, steht natürlich auf einem anderen Blatt...

e-gon

[himitsu]

Es ist die Structur im RAM, für diese WinAPI.
Es hat aber nichts mit der Struktur im Dateisystem (FAT16,FAT32,NTFS,ReFS,usw.) zu tun.

[e-gon]

Ich fand im Netz folgendes:

dwReserved0
Wenn das dwFileAttributes-Element das attribut FILE_ATTRIBUTE_REPARSE_POINT enthält, gibt dieses Element das Reparsepunkttag an.
Andernfalls ist dieser Wert nicht definiert und sollte nicht verwendet werden.

Wenn ihr recht hättet, wäre ja jeder Dateisystemeintrag mit FILE_ATTRIBUTE_REPARSE_POINT 4 Byte länger als einer ohne. Und bei Änderung des Attributs würde der Eintag entweder kürzer oder länger. Kann das wirklich sein?

e-gon

[jaenicke]

Zitat von e-gon:

Wenn ihr recht hättet, wäre ja jeder Dateisystemeintrag mit FILE_ATTRIBUTE_REPARSE_POINT 4 Byte länger als einer ohne. Und bei Änderung des Attributs würde der Eintag entweder kürzer oder länger.

Das klingt, als ob du vollkommen falsche Vorstellungen der Speicherung z.B. eines NTFS-Dateisystems hast.

[e-gon]

Zitat von jaenicke:

Zitat von e-gon:

Wenn ihr recht hättet, wäre ja jeder Dateisystemeintrag mit FILE_ATTRIBUTE_REPARSE_POINT 4 Byte länger als einer ohne. Und bei Änderung des Attributs würde der Eintag entweder kürzer oder länger.

Das klingt, als ob du vollkommen falsche Vorstellungen der Speicherung z.B. eines NTFS-Dateisystems hast.

Das will ich nicht ausschließen...

Zitat von jaenicke:

Solche Werte können auch genauso gut beim Auslesen dynamisch ermittelt werden oder eben gar nicht gesetzt werden. Die anderen Werte liegen auch nicht so als Datenstruktur herum, sondern werden als Attribut abgelegt.

Stimmt allerdings.

Zitat von jaenicke:

Speichern könntest du die Werte aber ohnehin nicht, da du die Datenstruktur nur zum Auslesen bekommst.

Ja, damit hat sich die Sache so oder so erledigt.

Werde mir die Datenstöme nochmals genauer anschauen.

Danke für die vielen hilfereichen Beiträge!

e-gon

[himitsu]

Gern nochmal:

Dieser Record hat garnichts mit der Speicherung auf der Festplatte gemeinsam.

* bei NTFS gibt es einmal einen Eintrag in der MasterFileTable, aber auch nochmal klassische Dateiverzeichnislisten, wie im FAT
* bei FAT32 liegen die Dateiinfos in einem FATRecord des Verzeichnisses, zusammem mit dem ShortFileName ... während der LongFileName einen oder mehrere "andere" FAT-Records in diesem Verzeichnis belegt, was dann beim Suchen zusammenkopiert wird.

Rate mal, warum es keine Funktion gibt, um diesen Such-Record wieder im Dateisystem zu speichern.

[gubbe]

Zitat von e-gon:

Werde mir die Datenstöme nochmals genauer anschauen.

Das bringt Dir nur leider nichts, wenn Deine Benutzer die Daten hin- und herkopieren, z.B. auf USB-Sticks mit FAT-Dateisystem oder ein NAS. Die Datenströme sind wie hier schon geschrieben wurde auf NTFS beschränkt. Meines Erachtens kein praktikabler Weg für Deinen Anwendungsfall.

Wenn Du sowieso im Hintergrund nach verschobenen Dateien suchst, wäre es wohl (wie himitsu vorschlägt) am besten, einen Hash-Wert zu merken, um die Dateien wiederzuerkennen. Die Hash-Werte müssen ja nur für neu hinzugekommene (oder umbenannte Dateien zum Vergleich) ermittelt werden. Das kann auch im Hintergrund laufen.

[Redeemer]

Es gibt die Möglichkeit, einen Fingerprint der Rohdaten zu machen. Dafür müsste man die Rohdaten aus der Datei herausholen. Und dafür braucht man tiefe Kenntnisse jedes unterstützten Dateiformats. Und scheitert doch bei Duplikaten.

[Gausi]

Zitat von gubbe:

Wenn Du sowieso im Hintergrund nach verschobenen Dateien suchst, wäre es wohl (wie himitsu vorschlägt) am besten, einen Hash-Wert zu merken, um die Dateien wiederzuerkennen. Die Hash-Werte müssen ja nur für neu hinzugekommene (oder umbenannte Dateien zum Vergleich) ermittelt werden. Das kann auch im Hintergrund laufen.

Das mit den Hashwerten funktioniert aber nur sinnvoll, wenn sichergestellt ist, dass sich die Dateien nicht verändern. Grade bei Audio-Dateien ist es aber durchaus üblich, dass sich diese immer wieder mal ändern - nicht der Audioteil, aber durchaus die Metadaten. So kann z.B. eine "Bewertung" in die ID3Tags geschrieben werden, die ja nicht unbedingt fix ist. mein Player merkt sich z.B. auch (natürlich optional, Opt-In) einen Abspielzähler darin.

[jaenicke]

Zitat von e-gon:

Ich verstehe die Kritik nicht so richtig. Die Variablen dwReserved0 und dwReserved1 sind in der Datenstruktur von WIN32_FIND_DATA hinterlegt. Es wird also dafür Speicherplatz reserviert und auch im Dateisystem zusammen mit CreationTime, LastAccessTime, LastWriteTime, dwFileAttributes auf der Festplatte abgelegt.

Wie kommst du darauf? Ich sehe dafür keinen Hinweis. Solche Werte können auch genauso gut beim Auslesen dynamisch ermittelt werden oder eben gar nicht gesetzt werden. Die anderen Werte liegen auch nicht so als Datenstruktur herum, sondern werden als Attribut abgelegt.

Speichern könntest du die Werte aber ohnehin nicht, da du die Datenstruktur nur zum Auslesen bekommst.