dwReserved1 nutzen?

[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.

[himitsu]

Für die Synology gibt es so eine Bilder/Videoplatform ... die Eine kann auch "Tags" in die Fotos/Videos schreiben (z.B. manuelle Tags, aber auch aus der BilderkennungsKI), damit sie beim Suchen genutzt werden können, auch wenn Dateien umbenannt/kopiert/verschoben werden.

[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

[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.

[Gausi]

Wenn irgendwo "Reserved" dran steht, dann sollte man diese Felder imho nicht für eigene Zwecke missbrauchen. Falls das überhaupt möglich ist.

Frage: was soll dein Programm denn machen, wenn der User eine Datei außerhalb deines Programms verschoben hat und der Datenbankeintrag daher ungültig geworden ist?

Soll dann die ganze Festplatte nach einer Datei durchsucht werden, die der in der DB entspricht? Und wenn der Anwender an der Ordnerstruktur was ändert, dann wird diese Suche für hunderte oder gar zig-tausende Dateien durchgeführt?

Ich denke, dass das dem Anwender klar sein sollte: Wenn man ein Dateiverwaltungstool nutzt, und die Dateien außerhalb des Tools verschiebt oder umbenennt, dann muss man im Anschluss die Dateien neu von dem Tool suchen lassen. Da einen Automatismus zu erwarten, halte ich für eine stark überzogene Anwender-Anforderung.

Wenn dein Tool zusätzliche Informationen zu den Dateien speichert (die ggf. auch vom Anwender bearbeitet werden können), dann gehören diese Infos imho in die Metadaten der Datei. Zumindest solange die Dateien dadurch nicht zu sehr aufgebläht werden. Für eine eindeutige ID sollte da aber auf jeden Fall Platz sein. Oder halt alternative Wege, die (wahrscheinlich) bei den üblichen Verzeichnis-Aktionen erhalten bleiben. Alternative Datenströme an den Dateien, oder je eine versteckte "Info-Datei" pro Verzeichnis. Eine 100%ige Garantie dafür, dass die Infos erhalten bleiben, gibt es aber natürlich nicht.

Bei mp3 sind die ID3-Tags z.B. oft voll mit "Private Frames" vom Windows Media Player, iTunes und anderen, die dann von der jeweiligen "Datenbank" dahinter benutzt werden. Amazon nutzt z.B. das Kommantar-Feld für eine eindeutige Song-ID, und in einem speziellen Private-Frame werden afaik u.a. verschlüsselt Informationen zum Käufer gespeichert. Filesharing von Amazon-Mp3s ist daher eine ganz blöde Idee.

Die Tag-Formate in anderen Audio-Dateitypen können ebenso dazu genutzt werden.

[e-gon]

Zitat von Gausi:

Frage: was soll dein Programm denn machen, wenn der User eine Datei außerhalb deines Programms verschoben hat und der Datenbankeintrag daher ungültig geworden ist?

Soll dann die ganze Festplatte nach einer Datei durchsucht werden, die der in der DB entspricht? Und wenn der Anwender an der Ordnerstruktur was ändert, dann wird diese Suche für hunderte oder gar zig-tausende Dateien durchgeführt?

Im Hintergrund scanne ich tatsächlich in regelmäßigen Abständen den "Musik-Bereich" der Festplatte nach verschobenen Dateien.

e-gon