Dateisystemcache invalidieren erzwingen

[Assarbad]

Ich lese ja gerade nicht Dateiinhalte (kein Öffnen der Dateien) ein, sondern welche Dateien und Verzeichnisse es gibt. Das ist der Cache den ich augenscheinlich nicht beeinflussen kann mit irgendwelchen Flags beim Einlesen.

Laufwerk trennen ist zwar auf Dauer etwas unpraktisch, aber wenn hier keiner eine bessere Methode kennt, bleib ich dabei.

Zitat von himitsu:

Damals, mit meinem FileSplitter, hatte ich ja ein bissl zu viel rumgetestet.

Gucke ich mir an. Vielleicht finde ich da ja Hinweise.

Zitat von p80286:

Da im "Normalfall" eine Datei gelesen wird, die überall liegen kann, Festplatte/SSD/USB/Netzlaufwerk, warum sollte man für jedes Speichermedium eine eigene optimale Verfahrensweise suchen?

Du mißverstehst. Es gibt tatsächlich noch andere Methoden als FindFirstFile/FindFirstFileEx und ich möchte die vergleichen. Und ja, Netzwerklaufwerke werden auch irgendwann in den Vergleich einfließen. Aber der Vergleich ist zwischen verschiedenen Methoden auf den jeweils gleichen Datenträgern. Ich muß nur den Zwischenspeicher irgendwie aus meinem Vergleich herausbekommen.

[himitsu]

In FAT/FAT32 sind Verzeichnisse auch "nur" sowas wie Dateien mit paar Records drin.
Bei großen Verzeichnissen mit massig Dateien wäre das schneller, wenn man die FAT selber parst, aber bei all dem kommst du ohne gewisse Rechte (Admin) nicht an doe Rohdaten.
(außer bei Wechsellaufwerken, ala USB-Sticks, wo man nicht so viele Rechte braucht)

Bezüglich NTFS könntest du die MFT auslesen (da gibt es irgendwo in der DP paar Codes dafür), das geht vorallem bei großen/tiefen Verzeichnisstrukturen wesentlich schneller, als sich überall mit FindFirstFile/FindNextFile einzeln durch alle Ebenen zu kämpfen.

[p80286]

Zitat von himitsu:

In FAT/FAT32 sind Verzeichnisse auch "nur" sowas wie Dateien mit paar Records drin.
Bei großen Verzeichnissen mit massig Dateien wäre das schneller, wenn man die FAT selber parst, aber bei all dem kommst du ohne gewisse Rechte (Admin) nicht an doe Rohdaten.
(außer bei Wechsellaufwerken, ala USB-Sticks, wo man nicht so viele Rechte braucht)

War da nicht mal was mit zwei Versionen der FAT damit man diese auf Fehler prüfen kann?
Ich kann mich erinnern, daß es da (funktionsfähige) Datenträger gab bei denen die zweite FAT nur Schrott war. Da mußt Du vorsichtig sein.

Gruß
K-H

[himitsu]

Standardmäßig gibt es die doppelt, um bei Fehlern die Zweite nehmen zu können.
Aber das könnte man einstellen, von 1 bis mehr. Vorallem bei kleinen Disketten für viel Daten konnte man so ein paar KB mehr an Daten drauf bekommen, genauso wenn man die Clustergröße größer festlegte, wurde dadurch die FAT kleiner, weil es weniger Cluster zu verwalten gibt.

Das Doppelte betraf vorallem das Hauptverzeichnis und die AllocationTabelle, also das, wo drin stand welcher Cluster belegt ist und mit welchem er als nächstes verlinkt ist.

[Assarbad]

Also die MFT zu parsen ist nur bedingt eine Option. Aus den von dir bereits genannten Gründen. Ist mir außerdem zu heikel sowas in einer Software einzusetzen wenn es Betriebssystemversionen betrifft die noch unterstützt werden. Wenn es um Systeme bis Vista geht, würde ich mich auch darauf einlassen, da man dort faktisch sicher sein kann, daß sich die entsprechenden Strukturen nicht retroaktiv ändern

FAT ist für mich im Großen und Ganzen kein Optimierungsziel, sondern maximal NTFS, reFS und Netzlaufwerke (unabhängig vom eigtl. Dateisystem).

Zitat von himitsu:

[...] als sich überall mit FindFirstFile/FindNextFile einzeln durch alle Ebenen zu kämpfen.

Das ist nur bedingt richtig. Die Bremse bei FindFirstFile und FindNextFile ist ja, daß dort standardmäßig allenfalls wenige Dateiinformationen auf einmal gelesen werden. FindFirstFileEx versucht das mit dem Flag FIND_FIRST_EX_LARGE_FETCH zu beheben, aber eben erst ab Windows 7. Damit werden dann die Informationen vieler Dateien in einem Zug gelesen und dann eben einzeln per FindNextFile zurückgegeben. Die Beschleunigung passiert aber dadurch, daß der Vorgang mit der hohen Latenz (Netzverkehr oder von Platte lesen) optimiert wird, indem man in einem Schwung viele Dateieinträge ausliest, statt nur sehr wenige. Indem man dann FindExInfoBasic benutzt, kann man noch ein paar Kopiervorgänge vermeiden (dann fällt der kurze Dateiname weg). Aber dann kann man eben auch direct die darunterliegenden Native API Funktionen benutzen. Und da will ich exakt austesten was genau wieviel Performanceschub bringt.

[p80286]

Interessante Idee, aber wie soll ich

Zitat:

If the string ends with a wildcard, period, or directory name, the user must have access to the root and all subdirectories on the path.

verstehen? Auf unseren Servern haben wir ungefähr diese Struktur
irgendwas\Daten\Buchhaltung
irgendwas\Daten\Vertrieb
irgendwas\Daten\Boss

und auf den PCs des Vertriebs ist irgendwas\Daten\Vertrieb als Laufwerk P: gemappt und die Berechtigungen sind entsprechend eingestellt. Worauf bezieht sich das erwähnte "root"? ist das P:\* oder irgendwas\Daten\Vertrieb ?
Im letzteren Fall wäre FindFirstFileEx schlicht untauglich.

Gruß
K-H

[Zacherl]

Zitat von p80286:

Worauf bezieht sich das erwähnte "root"?

Ziemlich sicher auf irgendwas\Daten\ . Bei Verwendung einer Wildcard am Ende des Strings benötigt die API dann natürlich auch die erforderlichen Rechte auf irgendwas\Daten\* , um Dateien in den Unterordnern suchen zu können. Die andere Möglichkeit ergibt - rein logisch betrachtet - zumindest wenig Sinn.