IsFileInUse Funktion erstellen

[BlueStarHH]

Hallo,

da ich mich momentan um andere Dinge kümmern muss, habe ich einen kleinen Auftrag für eine Funktion zu vergeben. In meinem Programm werden Dateien zum Lesen oder Schreiben geöffnet. Das ist nur möglich, wenn die Datei nicht durch ein anderes Programm geöffnet ist.

Ich möchte in einem Programm mit einer Funktion in der Art
IsFileInUse(const FileName: string; .......): Boolean

abfragen, ob eine bestimmte Datei in Benutzung ist oder nicht. Dabei soll dann der Windows-Standard-Dialog angezeigt werden, der in solchen Fällen auch z.B. vom Explorer angezeigt wird. In diesem Dialog muss angezeigt werden, welches Programm die Datei geöffnet hat und es muss eine Möglichkeit geben, erneut zu Prüfen, ob die Datei geöffnet ist. Man bekommt den Dialog angezeigt, wenn man z.B. ein Worddokuemnt öffnet und versucht es mit dem Explorer zu löschen.

So sieht das Dialog aus:
http://blog.speedproject.de/2007/06/...ird-verwendet/
Dort sind auch links zu Microsoft zu finden, wo das ganze dokumentiert ist.

Hier gibt es schon eine halbe Lösung:
http://blog.delphi-jedi.net/2010/11/14/is-file-in-use/

Ich benötige eine Lösung, die unter Delphi 2010 läuft mit allen Quellcodes. Die Jedi-Komponenten oder andere Komponenten sollen nicht genutzt werden um das ganze möglichst schlank zu halten. Ich möchte nicht wegen nur dieser einen Funktion die ganzen Jedis installieren. Andere Units dürfen nur genutzt werden, wenn diese nur per uses eingebunden werden müssen und in kommerziellen Projekten ohne weitere Kosten genutzt werden dürfen.

Bitte nennt mit per PN wie viel ihr dafür haben wollt. Bezahlt wird per Überweisung oder PayPal nach Eingang des Codes und Prüfung auf vollständige Umsetzung der Anforderungen.

[DeddyH]

Sry, wenn ich evtl. jemanden um Geld bringe, aber such doch einmal nach IsFileInUse, da gibt es schon einige Ansätze.

[BlueStarHH]

Zitat:

Zitat von DeddyH (Beitrag 1068616)

Sry, wenn ich evtl. jemanden um Geld bringe, aber such doch einmal nach IsFileInUse, da gibt es schon einige Ansätze.

Ja es gibt einige Ansätze. Ich habe auch selber einen Ansatz verlinkt. Ich benötige aber eine fertige Lösung. Und in den meisten Ansätzen kann nur abgefragt werden, ob die Datei genutzt wird. Jedoch nicht mit welchem Programm usw. D.h. nicht alle meine Anforderungen werden erfüllt.

[Luckie]

Bitte vergiss alle Ansätze ohne Treiber: http://www.michael-puff.de/Artikel/FileUnlocker.shtml

[BlueStarHH]

Zitat:

Zitat von Luckie (Beitrag 1068627)

Bitte vergiss alle Ansätze ohne Treiber: http://www.michael-puff.de/Artikel/FileUnlocker.shtml

Ein Treiber ist für meinen Zweck nicht nötig. Es soll einfach die in Windows Vista neu für diesem Zweck eingeführte WinAPI genutzt werden. Der in meinem Beitrag verwendete SpeedCommander nutzt auch keinen Treiber und das Beispiel bei Microsoft setzt diesen auch nich voraus. Bist Du sicher, dass man auch mit der neuen Vista-API einen Treiber braucht?

[Luckie]

Ziemlich. Microsoft wird das auch nicht ohne Treiber lösen. Und die API-Funktion wird auch einen Treiber nutzen. Wie heißt denn die API-Funktion, die es seit Vista dafür gibt?

[BlueStarHH]

Zitat:

Zitat von Luckie (Beitrag 1068633)

Ziemlich. Microsoft wird das auch nicht ohne Treiber lösen. Und die API-Funktion wird auch einen Treiber nutzen. Wie heißt denn die API-Funktion, die es seit Vista dafür gibt?

Schau Dir mal oben die Links in meinem ersten Post an. Und dort auf den Seiten wiederum die Links. Genauere Infos habe ich leider auch nicht.

[Assarbad]

Zitat:

Zitat von BlueStarHH (Beitrag 1068636)

Zitat:

Zitat von Luckie (Beitrag 1068633)

Ziemlich. Microsoft wird das auch nicht ohne Treiber lösen. Und die API-Funktion wird auch einen Treiber nutzen. Wie heißt denn die API-Funktion, die es seit Vista dafür gibt?

Schau Dir mal oben die Links in meinem ersten Post an. Und dort auf den Seiten wiederum die Links. Genauere Infos habe ich leider auch nicht.

Die API (COM) basiert darauf, daß die Programme sich bei Vista/7 melden und eine Datei als in Benutzung angeben. Adobe Reader tut das, viele andere Programme nicht.

[BlueStarHH]

Zitat:

Zitat von Assarbad (Beitrag 1068653)

Zitat:

Zitat von BlueStarHH (Beitrag 1068636)

Zitat:

Zitat von Luckie (Beitrag 1068633)

Ziemlich. Microsoft wird das auch nicht ohne Treiber lösen. Und die API-Funktion wird auch einen Treiber nutzen. Wie heißt denn die API-Funktion, die es seit Vista dafür gibt?

Schau Dir mal oben die Links in meinem ersten Post an. Und dort auf den Seiten wiederum die Links. Genauere Infos habe ich leider auch nicht.

Die API (COM) basiert darauf, daß die Programme sich bei Vista/7 melden und eine Datei als in Benutzung angeben. Adobe Reader tut das, viele andere Programme nicht.

Und für die Programme, die sich nicht melden gibt es sicherlich ein Fallback-Mechanismus. Ich vermute mal, dass dann einfach angezeigt wird, dass die Datei in Benutzung ist oder nicht. Alternativ muss man so einen Fallback-Mechanismus eben selbst machen. Wenn die neue API sagt, dass die Datei nicht in Benutzung ist, muss man nochmal mit der herkömlichen Methode prüfen, ob das wirklich stimmt. Also kein Hinderungsgrund die neue API zu nutzen.

[Luckie]

Zitat:

Zitat von BlueStarHH (Beitrag 1068659)

Wenn die neue API sagt, dass die Datei nicht in Benutzung ist, muss man nochmal mit der herkömlichen Methode prüfen, ob das wirklich stimmt. Also kein Hinderungsgrund die neue API zu nutzen.

Und warum nicht gleich die Fallback-Methode, wie auch immer sie implementiert ist, verwenden, wenn man sie so wie so zum Nachprüfen nutzt?

[BlueStarHH]

Zitat:

Zitat von Luckie (Beitrag 1068664)

Zitat:

Zitat von BlueStarHH (Beitrag 1068659)

Wenn die neue API sagt, dass die Datei nicht in Benutzung ist, muss man nochmal mit der herkömlichen Methode prüfen, ob das wirklich stimmt. Also kein Hinderungsgrund die neue API zu nutzen.

Und warum nicht gleich die Fallback-Methode, wie auch immer sie implementiert ist, verwenden, wenn man sie so wie so zum Nachprüfen nutzt?

Weil man meines Wissens einige Funktionen, die die neue API anbietet, mit dem herkömmlichen weg nicht bewerkstelligen kann. Z.B. den Programmnamen herausfinden, von dem Prog, das die Datei nutzt. Oder das Programm dazu veranlassen die Datei zu schließen. Oder weil man dann laut Deiner Aussage einen Treiber braucht, was umständlich ist als eben mal eine API-Funktion zu nutzen. Vielleicht brauch man die Fallback-Methode auch gar nicht. Das war nur Spekulation. Ich habe mich nicht tief damit beschäftig. Nur mal schnell quergelesen.

[Delphi-Laie]

Neben dem sicher erstklassigen Unlocker, der die Bindungen durchbrechen kann, gibt es auch noch zum Zwecke des bloßen Anzeigens solcher Sperren das Programm "Who lock me?".

[BlueStarHH]

Zitat:

Zitat von Delphi-Laie (Beitrag 1068696)

Neben dem sicher erstklassigen Unlocker, der die Bindungen durchbrechen kann, gibt es auch noch zum Zwecke des bloßen Anzeigens solcher Sperren das Programm "Who lock me?".

Ich brauche weder einen Unlocker noch ein Programm das mir die Sperren anzeigt. Ich brauche einen Quellcode, den ich in meinem eigenen Programm nutzen kann. Das wird von unbedarften Anwender genutzt, die Dateien immer mit Word oder Excel offen halten und dann in mein Programm importieren möchten. Das geht dann nicht, da Word oder Excel die Dateien exklusiv öffnen. Also sollte da die angesprochene Meldung gezeigt werden.

[Assarbad]

Zitat:

Zitat von BlueStarHH (Beitrag 1068699)

Ich brauche weder einen Unlocker noch ein Programm das mir die Sperren anzeigt. Ich brauche einen Quellcode, den ich in meinem eigenen Programm nutzen kann. Das wird von unbedarften Anwender genutzt, die Dateien immer mit Word oder Excel offen halten und dann in mein Programm importieren möchten. Das geht dann nicht, da Word oder Excel die Dateien exklusiv öffnen. Also sollte da die angesprochene Meldung gezeigt werden.

Siehe da. Ein wenig Kontext und es ist einfacher eine Aussage zu treffen, denn bei Word und Excel dürfte ohnehin die Methode mit der neuen API funktionieren.

Ansonsten verweise ich auf Chris: http://blog.delphi-jedi.net/2010/11/14/is-file-in-use/ und von dort aus https://jedi-apilib.svn.sourceforge....entExample.dpr

[tony.huerlimann]

// hier eine Function
// es braucht noch "uses shlobj" zu Beginn der unit Datei
// hope that helps : Gruss Tony

function IsFileInUse(fName:string) : boolean;
var HFileRes : HFILE;
begin
Result := False;
if not FileExists(fName) then
Exit;
HFileRes := CreateFile(pchar(fName),
GENERIC_READ or GENERIC_WRITE,
0, nil, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, 0);
Result := (HFileRes = INVALID_HANDLE_VALUE);
if not Result then CloseHandle(HFileRes);
end;

[DeddyH]

Nunja, damit bekommst Du aber auch nicht raus, welcher Prozess die Datei geöffnet hat.

[edit] Sry, Willkommen in der DP :dp: [/edit]

[BlueStarHH]

Zitat:

Zitat von Assarbad (Beitrag 1068702)

Ansonsten verweise ich auf Chris: http://blog.delphi-jedi.net/2010/11/14/is-file-in-use/ und von dort aus https://jedi-apilib.svn.sourceforge....entExample.dpr

Ich habe das FileIsInUseClientExample.dpr ausprobiert und eine XLSX Datei in Excel 2007 geöffnet. Beim Ausführen des Programm passiert nichts. Es wird gestartet und wieder beendet. Es erkennt also nicht, dass die Datei geöffnet ist. Der Speedcommander zeigt den gewüschten Dialog an, wenn ich die Datei löschen möchte. Also hat Excel die Datei auch exklusiv geöffnet.

[Dezipaitor]

Die Datei wird zwar von MS Office in der ROT registriert, doch die Implementierung nutzt nicht das IFileIsInUse Interface. Ein Indiz dazu ist, dass der Dialog keine Schalter für "Wechseln zu" und "Schließe Datei" besitzt, sondern "Wiederholen".

Naja, Speedcommander und Windows Explorer zeigen daher nur den Name der Anwendung an. Wenn es jedoch eine andere unbekannte Anwendung ist, dann zeigen beide auch nur "ein Programm" an.
Ich denke, dass ich die Implementierung kenne. Sie ist, wie man sieht, jedoch garnicht 100% treffsicher.

[BlueStarHH]

Zitat:

Zitat von Dezipaitor (Beitrag 1068724)

Naja, Speedcommander und Windows Explorer zeigen daher nur den Name der Anwendung an. Wenn es jedoch eine andere unbekannte Anwendung ist, dann zeigen beide auch nur "ein Programm" an.
Ich denke, dass ich die Implementierung kenne. Sie ist, wie man sieht, jedoch garnicht 100% treffsicher.

Welche Implementierung ist das? Wo kann ich den Code dazu finden? Hast Du ein kleinen Beispielcode? Danke!

[Dezipaitor]

Die gibt es noch nicht, das ist riesig aufwändig.
Und wenn ich so darüber nachdenke, dann wird es mit 64Bit schwierig, weil Delphi nur 32Bit Apps erstellen kann und daher nur 32Bit Dateilocks erkannt werden.

[himitsu]

PS: In irgendeinem älterem Thread zu diesem Thema schwirrt ein Programm von mir rum, welches den "billigen" Standardtest umgeht.

Also wo man einfach versucht die Datei exklusiv zu öffnen, welches ja praktsich nur dann geht, wenn noch kein anderer die Datei geöffnet hat (abgesehn von fehlenden Zugriffsrechten, wo man eh keinen Zugriff hat).
Mein programm hatte also Zugriff, obwohl CreateFile meinte, die Datei sei nicht in Benutzung
und das nur mit der StandardWinAPI, ohne irgendwelche Hooks oder andere Hacks.



Und dann gab es noch die unwahrscheinliche Variante, wo man direkt auf den Datenträger zugreift und von hinten rum in die Datei reinkommt, aber seit Vista sollten die meißten Programme eh keinenZugriff auf die Festplatten bekommen (fehlende Rechte) und dann isses ja nicht soooooo einfach die passenden Cluster/Sektoren zur gewünschten Datei rauszufinden.

[Dezipaitor]

Also, nach langem hin under her, habe ich nun eine Methode gefunden, die den Prozessnamen (d.h. Friendly Name) ermitteln kann. Ohne Treiber oder anderer schlimmer Sachen.
Wer Interesse hat, kann sich bei mir melden.

[generic]

Zitat:

Zitat von Dezipaitor (Beitrag 1069463)

Wer Interesse hat, kann sich bei mir melden.

Hau das doch bitte in die CodeLib der DP.

[himitsu]

Zitat:

Zitat von Dezipaitor (Beitrag 1069463)

Also, nach langem hin under her, habe ich nun eine Methode gefunden, die den Prozessnamen (d.h. Friendly Name) ermitteln kann.

Wenn man das Dateihandle vererben darf, ums in seinen Prozess zu kopieren und wenn die Datei mindestens 1 Byte groß ist (weil man's sonst nicht laden kann), dann gibt es einen Weg über MMF.

[alzaimar]

Ursprünglich ging es darum, einem DAU mitzuteilen, das die Datei, die von einer Anwendung importiert werden soll, gerade von WORD oder EXCEL blockiert ist.

Also ich würde das ganz einfach mit CopyFile lösen: Arbeitskopie erstellen und die dann importieren. EXCEL und WORD erlauben das, denn sonst würde man wohl kaum geöffnete Dateien per Mail versenden können.

Natürlich bekommt der unbedarfte Anwender dann keine Nachricht, das die Datei blockiert ist. Muss er aber auch nicht, oder?

[sh17]

Zitat:

Zitat von generic (Beitrag 1069467)

hau das doch bitte in die codelib der dp.

ack

[Dezipaitor]

Zitat:

Zitat von sh17 (Beitrag 1069498)

Zitat:

Zitat von generic (Beitrag 1069467)

hau das doch bitte in die codelib der dp.

ack

Tut mir leid, das werde ich nicht tun. Das war viel zu viel Aufwand, um es nun einfach so zu verschenken. Aber wer es wirklich will, kann sich gerne melden. Da wird sich sicher was machen lassen.

[Luckie]

Aber um das von Nico angesprochene Problem http://www.michael-puff.de/Artikel/FileUnlocker.shtml kommst du auch ohne Treiber nicht drumherum oder?

[Dezipaitor]

Naja, am besten ist es immernoch, wenn man dem Benutzer zeigen kann, welcher Prozess denn dafür verantwortlich ist. D.h. vielleicht ist ja noch ein MS Word geöffnet irgendwo.
Meine Funktion nutzt neben IFileIsInUse noch andere Methoden ohne Treiber, um den benutzerfreundlichen Namen (z.B. Microsoft Word) und die ProzessID herauszufinden.