Entwickler-Ecke
Dateizugriff - Welcher Prozess hat Datei geöffnet
Knulli - Mi 01.08.07 15:58
Titel: Welcher Prozess hat Datei geöffnet
Hallo Forum,
ich schreibe Daten in eine Datei mit folgender Code-Sequenz:
Delphi-Quelltext
1:
2:
3:
4:
5:
| AssignFile(DatFile, SR.FName+'.Dat');
Reset(DatFile);
Seek(DatFile, FileSize(DatFile));
Write(DatFile, MessArray[aRecNum]);
CloseFile(DatFile); |
Manchmal gibt es nach mehreren Stunden problemfreien Betriebes eine Exception "Datei nicht gefunden". Ich vermute, daß ein anderer Prozess (Virenscanner??) auf die Datei lesend zugreift und deshalb die Exception kommt.
Jetzt die Frage: Wie bekomme ich heraus, welcher Prozess (möglichst mit DLL/EXE-Name) Ursache dafür ist?
mfg Knulli
Chryzler - Mi 01.08.07 16:09
Wenn ein anderer Prozess auf die Datei zugreift, dann gibts normalerweise eine "Zugriff verweigert"-Exception. Ich glaube eher, dass da dein Programm schuld ist. ;) Sonst würden ja in allen anderen Programmen auch reglemäßig "Datei nicht gefunden"-Exceptions auftauchen.
jaenicke - Mi 01.08.07 16:12
Ein Virenscanner greift normalerweise so zu, dass du dennoch zugreifen kannst. Wie bereits
Chryzler sagte wird das kein Zugriffsfehler sein.
Erstell am besten ein Log, in dem du vor dem versuchten Zugriff loggst, ob die Datei existiert. Dann siehst du in der Log-Datei existiert / existiert nicht: dateiname oder so ähnlich...
Knulli - Mi 01.08.07 16:36
Das mit der Log-Datei werde ich mal machen (armer Kunde, muß mir helfen meinen Bockmist zu finden), aber interessant wäre es trotztem mal herauszubekommen (selber programmieren!), welcher Prozess eine bestimmte Datei am Wickel hat. Das wäre doch endlich mal eine Fehlermeldung, mit der man was anfangen könnte: Kann Datei XYZ nicht schreiben, weil abc.exe gerade daran rumwurschtelt.
Hat jemand eine Idee, wie ich herausbekommen kann, welche Delphi Funktion überhaupt die "Datei nicht gefunden" Exception werfen kann. Ich habe mir mal die VCL angesehen, da bekommt man ja graue Haare! Irgendein ErrorHandler, der ein paar spezielle Fehler rausfischt und alles andere sind IO-Fehler. Das kann ja von überall kommen!
Knulli
Jakob_Ullmann - Mi 01.08.07 18:03
Ich denke nicht, dass das geht, da beim Umgang mit AssignFile und Co. beim Öffnen jeder, der einen guten Programmierstiel hat, die Datei mit CloseFile wieder schließt und demnach die Datei ja nicht geöffnet hat sondern sich nur die Daten holt.
Du kannst ja mal alle Programme schließen und dann dein Programm mal laufen lassen. ;)
jaenicke - Mi 01.08.07 18:06
Mit den JEDIs ist es AFAIK möglich die Zeile, in der der Fehler aufgetreten ist, anzeigen zu lassen. Dafür müssen die Debugdaten für JEDI aktiviert werden, ich glaube, das war ein MenuItem unter Projekt, wenn die installiert sind (oder in den Projektoptionen, das habe ich vergessen).
F34r0fTh3D4rk - Mi 01.08.07 18:09
| Knulli hat folgendes geschrieben: |
| Das mit der Log-Datei werde ich mal machen (armer Kunde, muß mir helfen meinen Bockmist zu finden), aber interessant wäre es trotztem mal herauszubekommen (selber programmieren!), welcher Prozess eine bestimmte Datei am Wickel hat. Das wäre doch endlich mal eine Fehlermeldung, mit der man was anfangen könnte: Kann Datei XYZ nicht schreiben, weil abc.exe gerade daran rumwurschtelt. |
Unlocker kann das, das programm kann prozesse abschießen, wenn man gerade zB eine Datei löschen will, auf die ein anderes programm zugreift.
mfg
jaenicke - Mi 01.08.07 18:12
Ja, da gibts viele Tools dafür, der ProcessExplorer zeigt einem auch an, welche Handles welches Programm offen hat und sucht danach. Das Problem ist aber denke ich gar nicht, dass ein anderes Programm da gleichzeitig zugreift.
(Und selbst wenn es so wäre, dann wird der Kunde mit den Tools vielleicht nicht so gut klarkommen...)
Knulli - Do 02.08.07 10:25
Unlocker hab ich auch schon gefunden und Ihr werdet es nicht glauben, ich habe den Autor mal angemailt, wie er herausbekommt, welcher Prozess eine Datei geöffnet hält: ZwQueryObject kam als Antwort. Werde ich mir heute mal durchlesen, was das ist. Wenns ne schnucklige Funktion wird, werde ich die hier mal posten.
Knulli
Knulli - Do 02.08.07 15:57
Hab's schon geahnt, als ich in der MSDN Library nach ZwQueryObject gesucht habe: 0 Treffer. Googlen ergab was von versteckten Windows-Funktionen.
Da laß ich die Finger von, ist nichts für meines Vaters Sohn...
Danke an alle.
Knulli
Logikmensch - Fr 03.08.07 07:12
Um nochmal auf den Code des Autors zurückzukommen, nehme ich doch an, dass SR vom Typ TSearchRec ist. Der Code ist deswegen nicht thread-sicher, weil der Dateizugriff nicht explizit den Pfad der Datei mit angibt. Wenn man das unterlässt, erfolgt der Dateizugriff auf dem Pfad des 'aktuellen Verzeichnisses' von Windows und darauf kann man eh nicht vertrauen, weil der sich u.U. ständig ändern kann. Daher vermute ich die Fehlermeldungen dass die Datei manchmal nicht gefunden wird.
Ich übergebe bei Dateisuchen mittels FindFirst/FindNext auch immer den Suchpfad und übergebe ihn auch an die sich rekursiv ausführende Ordner-Suche, so dass der Datei-Zugriff immer den Pfad zur Verfügung hat.
Nur so als Anmerkung. :-)
Knulli - Fr 03.08.07 18:00
Nee, SR ist vom Typ TSetRec (eigener Typ, in dem meine Programmeinstellungen stehen). Trotzdem danke für den Tip. Werde mich aber bemühen meinen geposteten Code in Zukunft von solchen Dingen zu befreien.
Knulli
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!