Welcher Prozess hat Datei geöffnet

Knulli · Verfasst: Mi 01.08.07 15:58

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 · Beiträge: 1097 Erhaltene Danke: 2

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 · Verfasst: Mi 01.08.07 16:12

Ein Virenscanner greift normalerweise so zu, dass du dennoch zugreifen kannst. Wie bereits user profile icon

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 · Verfasst: 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 · Verfasst: 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 · Verfasst: 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 · Verfasst: 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 · Verfasst: 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 · Verfasst: 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

Ehemaliges Mitglied Erhaltene Danke: 1

Guck mal hier: www.delphipraxis.net...amp;highlight=unlock
Das wird nicht eine einfache Funktion werden.

Oder hier: www.codeguru.com/Cpp...es/article.php/c2827

Knulli · Verfasst: 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 · Beiträge: 390 Win XP Delphi 2007 Prof., XE2, XE5

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. :-)

_________________
Es gibt keine Probleme - nur Lösungen!

Knulli · Verfasst: 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

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme