Prozess finden, der Datei offen hat

[Luckie]

Habs: http://www.delphipraxis.net/53005-da...freigeben.html
Zitat von dir:

Zitat:

Indem man die Handles des Prozesses auflistet und deren Namen findet. Das geht zwar auch ohne Treiber, aber nur in einem bestimmten Fall. Daher vermutlich der Treiber.

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1059635)

Habs: http://www.delphipraxis.net/53005-da...freigeben.html
Zitat von dir:

Zitat:

Indem man die Handles des Prozesses auflistet und deren Namen findet. Das geht zwar auch ohne Treiber, aber nur in einem bestimmten Fall. Daher vermutlich der Treiber.

Puh, mein früheres Ich :glaskugel:

Aber Nico hat recht, und zwar hier:

Zitat:

Zitat von NicoDE (Beitrag 408216)

Zitat:

Zitat von Olli

ZwQuerySystemInformation und ZwQueryObject[...]

Der Treiber ist deswegen notwendig, weil die Abfrage des Namens eines Dateiobjektes (Dateien, Verzeichnisse, Pipes, MailSlots, ...) bei synchronisierten Objekten solange benötigt bis die aktuelle Operation abgeschlossen ist (und das kann ewig dauern). Da zum Beispiel der Service Control Manager (SCM) Pipes verwendet um mit Service-DLLs zu kommunizieren, gibt es eine Menge solcher Objekte. Zudem gibt es aus dem Benutzermodus keinen sicheren Weg um Dateien von Pipes und/oder MailSlots zu untercheiden. Der Treiber löst das erste Problem üblicherweise dadurch, dass er den IRP zur Abfrage des Objekts selbst erzeugt. Das zweite Problem kann ebenso im Treiber (mit Hilfe des IFS-Kits) gelöst werden (MailSlots oder Pipes sind an Flags erkennbar).

Kurz, für eine saubere Lösung kommt man nicht um einen Treiber herum.

... das war der Hasenfuß.

I stand corrected :zwinker:

[himitsu]

Zitat:

Zitat von Assarbad (Beitrag 1059633)

Aber die neue Suche finde ich schröcklich ... :shock:

für mich findet die och selten was :cry:

google: "site:delphipraxis.net suchwort(e)"

[Luckie]

Zitat:

Zitat von Assarbad (Beitrag 1059637)

Aber Nico hat recht, und zwar hier:

Zitat:

Zitat von NicoDE (Beitrag 408216)

Zitat:

Zitat von Olli

ZwQuerySystemInformation und ZwQueryObject[...]

Der Treiber ist deswegen notwendig, weil die Abfrage des Namens eines Dateiobjektes (Dateien, Verzeichnisse, Pipes, MailSlots, ...) bei synchronisierten Objekten solange benötigt bis die aktuelle Operation abgeschlossen ist (und das kann ewig dauern). Da zum Beispiel der Service Control Manager (SCM) Pipes verwendet um mit Service-DLLs zu kommunizieren, gibt es eine Menge solcher Objekte. Zudem gibt es aus dem Benutzermodus keinen sicheren Weg um Dateien von Pipes und/oder MailSlots zu untercheiden. Der Treiber löst das erste Problem üblicherweise dadurch, dass er den IRP zur Abfrage des Objekts selbst erzeugt. Das zweite Problem kann ebenso im Treiber (mit Hilfe des IFS-Kits) gelöst werden (MailSlots oder Pipes sind an Flags erkennbar).

Kurz, für eine saubere Lösung kommt man nicht um einen Treiber herum.

... das war der Hasenfuß.

Genau die Begründung meinte ich. :P Also hatte ich doch Recht, dass man für eine saubere Lösung nicht um einen Treiber drum rum kommt. ;) :firejump:

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1059639)

Genau die Begründung meinte ich. :P Also hatte ich doch Recht, dass man für eine saubere Lösung nicht um einen Treiber drum rum kommt. ;) :firejump:

Hattest du. Die Begründung sollte man ganz groß ausdrucken und irgendwo aufhängen, denn sie relativiert das "eigentlich reicht die Native API" ;)

[Luckie]

Ich habe es für mich mal notiert: http://www.michael-puff.de/Artikel/FileUnlocker.shtml

[Satty67]

Wie löst das eigentlich Handle?

...oder ist das an der Frage vorbei bzw. unvollständig?

[Assarbad]

Zitat:

Zitat von Satty67 (Beitrag 1059773)

Wie löst das eigentlich Handle?

...oder ist das an der Frage vorbei bzw. unvollständig?

Müßte man gucken. Sysinternals packt Treiber immer als Ressource in die EXE. Wenn das nicht der Fall ist, hat Mark vielleicht durch seinen Einblick bei MS Zugriff auf einen Trick der das Problem aus Nico's Hinweis umgeht. Zeit es zu reversen habe ich aber nicht - arbeite derzeit an WinDirStat.

[Assarbad]

Habe mal grob drübergeschaut. Ist in den Ressourcen. Erstmal ist die x64-Version mit enthalten und zudem noch mindestens einen x64-Treiber enthält und die (äußere) 32bit-EXE enthält ebenfalls einen 32bit-Treiber.

[Dezipaitor]

Ich glaube ab Vista (oder Win7) gibt es eine neue API, die es ermöglicht den Namen und Grund einer Dateisperrung herauszufinden. Dazu muss aber der Prozess, der die Datei öffnet, diesen Grund auch angeben. Leider ist mir grad entfallen, wie die API heißt.