Prozess finden, der Datei offen hat

[hoika]

Hallo,

ich will eigentlich meinem Innosetup helfen,
wenn Dateien im System überschrieben werden sollen.
Davor will ich prüfen, ob die Datei offen ist,
und wenn ja, von wem sie geöffnet ist.


Heiko

[Assarbad]

Puh, mit InnoSetup kenne ich mich nicht aus. Und "Kontext" meinte übrigens den Kontext in dem Nico seine Aussage gemacht hat.

[Luckie]

Es ging darum den Prozess zu finden, der eine oder mehrere Dateien geöffnet hat und so den Zugriff auf die Dateien blockiert hat. Eventuell findet man den Beitrag hier im Forum noch.

[Assarbad]

Zitat von Luckie:

Eventuell findet man den Beitrag hier im Forum noch.

Habe es gerade versucht. Aber die neue Suche finde ich schröcklich ...

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

Puh, mein früheres Ich

Aber Nico hat recht, und zwar hier:

Zitat von NicoDE:

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

[Luckie]

Zitat von Assarbad:

Aber Nico hat recht, und zwar hier:

Zitat von NicoDE:

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. Also hatte ich doch Recht, dass man für eine saubere Lösung nicht um einen Treiber drum rum kommt.

[himitsu]

Zitat von Assarbad:

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

für mich findet die och selten was

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