Ich liebäugele ja immer sehr mit dem direkten Auslesen der MFT, wenn es um die Auflistung von Dateien geht. Das ist hier aber alles andere als populär; vermutlich, weil man dazu Administratorrechte braucht?

Irgendwann habe ich mich dann mal gefragt, wie Microsoft das eigentlich selbst macht. Die müssen doch auch an die MFT ran, da gibt es doch überhaupt keinen anderen Weg. Vermutlich gehen die dann irgendeinen verschachtelten Weg, der die Adminrechte umgeht. Aber warum geht das dann - im Vergleich zum MFT-Direktauslesen - so langsam?

Die Treiber des Dateisystems laufen in Hintergrundprozessen, die unter dem System-Account laufen, nicht unter dem des Benutzers. Dessen Programme müssen daher per inter processs communication mit den Treibern "sprechen", und Daten über Prozess- und Threadgrenzen zu transportieren ist halt mit ziemlichen overhead verbunden. Außerdem ist ein NTFS-Dateisystem wesentlich komplexer als das gute alte FAT, mehr wie eine Datenbank organisiert. Zudem enthält das Dateissystem auf einem heutzutage typischen Rechner hunderttausende bis millionen Dateien, das limitiert halt schon was das OS da von der Directorystruktur im Filecache halten kann. Und das Filesystem ist eine shared resource, auf das viele der laufenden Prozesse (und das sind oft mehr als hundert) zugreifen können...

Zitat von peterbelow:

Die Treiber des Dateisystems laufen in Hintergrundprozessen, die unter dem System-Account laufen, nicht unter dem des Benutzers...

Das ist schon mal ein Hinweis, der aufklärt. Der Inhalt der MFT muss aber gar nicht im Cache gehalten werden; insbesondere bei SSDs kann sie Sekundenbruchteilen gelesen werden (ich weiß wohl, wie die MFT aufgebaut ist und habe ja auch den Code, um sie auszulesen). Overhead OK, aber die zeitlichen Unterschiede sind doch so gravierend, dass ich mir derartige Verzögerungen nur schwer erklären kann. FindFirstFileW ist ja auch dann langsam, wenn sonst keine Prozesse auf die MFT zugreifen.

Was hier langsam ist, dass FindFirstFile/FindNextFile die Dateien sortiert und bei jedem Aufruf auch versucht zu synchronisieren, falls sich zwischenzeitlich durch andere Programme was in dem Verzeichnis geändert hat.


FindFirstFileEx mit FIND_FIRST_EX_LARGE_FETCH

Es gab hier aber vor vielen Jahren irgendwo im Forum mal einen Code, um die MFT direkt auszulesen (fand/finde ihn aber nicht mehr)

Aber selbst in der WinAPI kann man sich auchproblemlos an LowLevelPAI wenden.
FindFirstFile ruft intern ja auch nur andere APIs auf, aber deren Verwendung ist dann etwas "problematischer".
Oft nicht offiziell dokumentiert und MS sagt dazu, dass man sie nicht direkt verwenden solle, da sie sich in nachfolgenden Windowsversionen ändern könnten. (sowas passiert aber dennoch recht selten, bzw. bisher fast nie)



Es gibt auch noch andere Zugriffe.
z.B. IShellFolder (welches der Explorer, bzw. im Delphi der FileOpenDialog nutzt) ... komischer Weise kommt mir es so vor, als wenn das manchmal schneller ist, obwohl ich es langsamer vermuten würde.
Und selbst über WMI könnte man das Dateisystem auslesen. (wenn ich mich richtig erinnere)

Zitat von himitsu:

Was hier langsam ist, dass FindFirstFile/FindNextFile die Dateien sortiert und bei jedem Aufruf auch versucht zu synchronisieren, falls sich zwischenzeitlich durch andere Programme was in dem Verzeichnis geändert hat.

Daran kommen mir aber Zweifel. MSN selbst sagt "This is because FindFirstFileEx does no sorting of the search results." zudem "Note: In rare cases or on a heavily loaded system, file attribute information on NTFS file systems may not be current at the time this function is called. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function." Speziell im Fall von Hardlinks habe ich mich an GetFileInformationByHandle gehalten, aber auch nicht immer mit Erfolg.

Außerdem führen die noch aus: "If you are writing a 32-bit application to list all the files in a directory and the application may be run on a 64-bit computer, you should call Wow64DisableWow64FsRedirection before calling FindFirstFileEx and call Wow64RevertWow64FsRedirection after the last call to FindNextFile." Das habe ich in meiner Anwendung tatsächlich auch gemacht; aber ich habe noch nie gesehen, dass es ein anderer macht, zum Beispiel hier in der DP in den diversen Abhandlungen über die schnellste Dateisuche.

Bezüglich des MFT-Codes meintest du vielleicht dieses Thema. Ich hatte seinerzeit mal intensiv nach Delphi-Code gesucht und den von Alexander Freudenberg gefunden. Er hat seinen Code hier zur Verfügung gestellt. Ich fand den Code zwar schwer lesbar, aber enorm hilfreich; allerdings hat Freudenberg Hardlinks nicht beachtet, weswegen ich den Code dahingehend ausgebaut habe. Die Resultate sind in der Anwendung schon beeindruckend. Leider muss man, wenn man ihn verwendet, nicht nur das Programm mit Adminrechten starten, sondern auch Delphi. Das war mir irgendwie nicht so angenehm (auch wenn ich Emba natürlich total vertraue...)

Ja, Admin-Programme, bzw. Programme mit "anderen" Rechten zu debuggen, ist nicht so schön/leicht.

Bei allen neuren Compilern, außer Win32, wird das intern eh schon gemacht (für Win64 ja nötig, wobei es Delphi lokal automatich macht),
aber du kannst auch selber das nutzen, den RemoteDebugger, bzw. PAServer.
In diesem Fall muß dann nur der Debugger/PAServer als Admin gestartet werden. (und natürlich das Programm selber)

Zitat:

Das war mir irgendwie nicht so angenehm

Es hat auch noch andere Probleme.
Wenn dein "Admin" ein anderer Benutzer ist, dann fehlt da drüben auch noch was in Registry und Verzeichnissen,
womit dir in der IDE eventuell auch etwas fehlen könnte. (Einstellungen, Komponenten, ...)


Du könntest auch in der WindowsSandbox (der neuen VM) rumspielen.
Dieses Windows in der VM hat garkeine Benutzerverwaltung (ähnlich einem WinPE oder RE) und alle Programme laufen immer mit vollen Rechten.
Die IDE bekommst da nicht rein, weil die Platte zu klein ist, aber via RemoteDebugger kein Problem.

Hatte mal bissl rumgespielt und versucht die automatisch in die Delphi-IDE zu bekommen.
https://www.delphipraxis.net/207151-...s-sandbox.html