Prozess finden, der Datei offen hat

[hoika]

Hallo #,

geg. ist der Name einer Datei (incl. Pfad):
Ich möchte jetzt herausbekommen, welcher Prozess diese Datei offen hat (falls es einen gibt).

Folgender C-Code macht das für ein Verzeichnis.
http://www.codeproject.com/KB/shell/...ileFinder.aspx


Hat jemand schon eine Delphi-Version dafür gefunden ?


Oder ohne das NtQuerySystemInformation, laut MSDN ist das eine OS-interne Funktion,
die sich von OS-Version zu OS-Version ändern kann.



Danke


Heiko

[Luckie]

Dafür wirst du einen Dateisystemtreiber brauchen, um zuverlässige Informationen zu bekommen. Es gibt auch Lösungen für den User-Mode, nur sind diese nicht zuverlässig: http://www.michael-puff.de/Programmi...lphi/Programme -> FileUnlocker.zip

[hboy]

ntQuerySystemInformation funktioniert von von NT4 ab eigentlich recht gut, ob der Spaß ab NT6 und neuer noch funktioniert, kann ich nicht sagen. Generell ist es aber wenig verwunderlich, dass ein so direkter Zugriff auf Systeminformationen versionsspezifisch ist.

Vielleicht einen Blick wert: http://www.openrce.org/forums/posts/46

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1052531)

Dafür wirst du einen Dateisystemtreiber brauchen, um zuverlässige Informationen zu bekommen.

Stimmt nicht. Es wird nichtmal ein Dateisystemfilter benötigt. "hboy" ist am nächsten an der Lösung. Und die Native API wird meist nur erweitert und selten wirklich grundlegend geändert. Eine Garantie ist das allerdings in der Tat nicht.

[Luckie]

Also die Aussage stammt ursprünglich von Nico. Und wenn du dir meinen FileUnlocker (noch ohne Unlock-Funktion) anguckst, dann funktioniert er nicht zuverlässig. Auf meinem heimrechner fzunktioniert er auf anderen Rechnern bleibt er hängen.
http://www.michael-puff.de/Programmi...leUnlocker.zip

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1059608)

Also die Aussage stammt ursprünglich von Nico.

Dann gib doch mal Aussage und Kontext. Ich bin mir ziemlich sicher, daß es nicht um das selbe Problem ging.

Allerdings kann es sein, daß eine 32bit-Anwendung auf 64bit-Windows Probleme bekommt. Aber das müßte man erstmal testen ...

[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:

Zitat von Luckie (Beitrag 1059629)

Eventuell findet man den Beitrag hier im Forum noch.

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

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

[Luckie]

Ginko hilft ;)

[Assarbad]

Zitat:

Zitat von Dezipaitor (Beitrag 1059809)

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.

Wäre interessiert. Mir ist noch keine untergekommen, aber Windows Installer hat seit langem (m.E.n. auch vor Vista) einen Dialog der zum Schließen diverser Anwendungen auffordert wenn die eine Datei benutzen die geändert werden soll oder so. Ansonsten benutzt MSI eben einfach die gute alte Methode mit Umbenennen.

[Dezipaitor]

AFAIK SpeedCommander nutzt diese API bereits. Man kann dann auch den Titel der Anwendung sehen.

[Assarbad]

Nach etwas Recherche: IFileIsInUse (ab Vista)