Dateiinfos lesen (schnellste Variante?)

[jobo]

Dir wird wohl nichts anderes übrig bleiben, als die Infos, die Du anzeigen willst, Stück für Stück aus den Files zu kitzeln (meist).
Im Extremfall ist das aufwändig und es entstehen (schon betriebssystemseitig) Hilfskonstruktionen wie z.B. die Thumbnails Dateien für Bilder oder formatspezifisch eben das, wo Du gerade baggerst, Headerinfos oder auch Embedded Preview Images. (nebenbei, solche Mechanismen kannst Du natürlich auch nutzen-also mühsam erungene Dateiinfos puffern, solange die Datei unverändert bleibt)
Wenn du das so schnell es geht auslesen möchtest finde ich das schon mal löblich. Man sieht trotz dieses relativ selbstverständlichen Gedankens immer wieder schlechte Lösungen, die auch noch so frech sind, sich im Explorer einzuzecken und die Anzeige eines Ordners zum Geduldspiel werden lassen.
Wie auch immer die formatspezifische Implementierung bei Dir aussehen wird, ich empfehle Dir Multithreading sowie Nebenläufigkeit als Implementierungsbasis des Gesamtprozess. Dass man nicht ungefragt vorhandene (Ordner)Einstellungen überschreibt, sollte ja selbstverständlich sein.

[KodeZwerg]

Ich nutzte damals mehrere 4KB puffer, datenköpfe einlesen, parallel die puffer nach headern/signaturen prüfen, die dann wiederum an entprechende implementierungen weitergeleitet wurden.
Spezialfall bei mir waren halt die typen wo infos eher am dateiende hinterlegt sind. Da ging ich genauso vor allerdings mit 8 - 10 kb puffer und hab meine signaturen rückwärts gegengeprüft.
Am schlimmsten sind multimedia daten die sich aus den vorhanden chunks zusammensetzen und aufgerechnet werden müssen, die hab ich außen vor gelassen. (realmedia war des glaube ich)

edit
Am schlimmsten...*
sind auch dateien die nur über sprungziele zum ergebnis führen und mittendrinn "kaputte" vorkommen. Diesen fall hatte ich bei Entwicklung nicht berücksichtigt, also das sollte auch gecheckt werden nicht das man übers dateiende hinaus was lesen mag

[MicMic]

Naja, noch probiere ich ein wenig herum an verschiedenen Dateitypen aber werde wohl schon für andere Ideen Ausschau halten
Es kommt ja auch noch dazu, dass es zu manchen Dateitypen noch verschiedene Versionen gibt. Dies muss man alles prüfen. Also doch viel viel Arbeit wenn man es richtig machen will. Danke für Eure Tipps und Anregungen.

Gruß Mike

[Luckie]

Wozu brauchst du das denn?

[KodeZwerg]

Ps: Je nach Anzahl der Dateien könnte es schneller über CreateFile / THandleStream abgearbeitet werden, da die Daten von Windows (soweit ichs in Erinnerung habe) nicht gecached werden... einfach mal rumprobieren / benchen.

[himitsu]

TFileStream und auch alles andere im Delphi arbeitet ebenfalls mit nur CreateFile.
Und da nirgendwo explizit angegeben wird, dass dort der Cache deaktiviert werden soll, wird somit immer durch den Cache gegangen, auch wenn es sich um einen Datenträger mit deaktivertem Schreibcache handelt, geht es erst durch den Cache des Windows, nur wird da dann eben sofort das Speichern angestoßen.

Also eher andersrum. Man müsste den FileCache deaktivieren, aber dann musst du aufpassen, dass du nur komplette Sektoren ausliest, weil sonst knallt es.
Dann wäre das (einmalige) Lesen extrem vieler und/oder großer Dateien schneller, welche nicht in den Cache (RAM) passen würden, also wo der Cache ständig nachladen und rauswerfen muß und wobei vor allem der Programmspeicher kräftig ausgelagert wird.

Bzw. man könnte zumindestens dem Cache sagen, dass man nur vorwärs liest (kein Random-Access) und womit "theoretisch" der Cache dafür sein Verhalten optimieren könnte.
(Bauchgefühl bemerkt dabei allerdings keinen Unterschied, aber theoretisch könnte der Cache dabei wissen, dass man diese gecachten Daten nur einmal braucht, kann sie sofort nach dem Zugrif wieder entladen, anstatt andere Dinge aus dem RAM zu werfen, wie wenn er nur nach dem Alter/letzter Zugriff der Daten ginge)

FILE_FLAG_SEQUENTIAL_SCAN
FILE_FLAG_NO_BUFFERING
FILE_FLAG_WRITE_THROUGH