Um eine BackupFunktion für meine Programmdaten zu erstellen,
- zippe ich den kpl. Inhalt meines AppDat Ordners in eine datei (darin speicher ich ebenfalls die Daten)
- überspiele/ersetze im BackupFall den aktuellen AppData Ordner mit den im Zip-File gespeicherten Backup.


soweit so gut. Ich habe allerdings das Problem dass mir das aus sicherheitsgründen notwendige "Umbenennen" des AppData Ordners nicht gelingt (ich will diesen nicht gleich löschen sondern erst umbennnen um ihn notfalls wieder zurückerhalten zu können).
Vermutlich ist mein Problem das ich in irgendeiner meiner vielen Routinen eine Datei nicht wieder geschlossen habe (es sind sehr viele.....) und deswegen das rename des ganzen Ordners fehlschlägt.

Im Endeffekt wäre mir damit geholfen wenn ich herausfinden könnte "welche Dateien dort aktuell noch geöffnet sind".
Dann könnte ich die dafür verantw. bugs im Code beseitigen und dann sollte das laufen.

Nach etwas Forensuche wäre hierfür die JEDi VCL eine option. Mit dieser habe ich allerdings mit meinem XE7 das problem dass dies nocht nicht unterstützt wird.
Help Please

vG Martin

Hmm..

wenn mit ein bisschen Google hättest Du sowas gefunden

zusammenfalten · markieren

Delphi-Quellcode:

function FileInAccess(AFileName : Widestring):boolean;
var
  HFileRes: HFILE;
begin
  HFileRes := CreateFileW(PWideChar(AFileName),
                         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;

Dies entspricht auch dem Microsoft-Vorschlag (leider Link nicht zur Hand..).

Es kann nur zu Problemen kommen, wenn Du das mit ReadDirectoryChangesW/GetQueuedCompletionStatus einsetzt.
Hier ist es bei einem Tool von uns (Überwachung von Verzeichnissen und Einlesen neu erstellter Dateien) zum Problem gekommen, das wir das CreateFile bekommen haben, dann geprüft haben ob das File 'Frei' ist.
Jedoch sind wir teilweise mit der obrigen Prüfung so schnell gewesen, dass wir dem anderen Programm, welches die Datei schreiben sollte zwischen dessem CreateFile und WriteFile dazwischen gegrätscht sind.

Denn Windows macht intern erste ein CreateFile -> CloseFile -> ReopenFile (mit Prozessexplorer beobachtet) und wir sind dann zwischen CloseFile und Reopen dazwischen gegangen und haben mit der Prüfung das File bereits geöffnet

Solange Du aber nur deine eigenen Dateien Überprüfst, sollte es gehen...

Entscheidend sind hier Process Monitor von Microsoft und auch der schon genannte Process Explorer von dort.

Mit den beiden Tools kannst du sehen welche Handles auf Dateien noch offen sind (Process Explorer, im Menü "Suche Handles") und ggf. auch sehen wann wie darauf zugegriffen wird (Process Monitor).

Auch die Suchfunktion in der DP liefert garantiert mehrere Funde.

Wer nicht mit PChar und WinAPI hantieren will, kann auch die passenden Wrapper verwenden.

markieren

Delphi-Quellcode:

function CheckFileAccess(const FileName: string): Boolean;
var
  H: THandle;
begin
  H := FileOpen(FileName, fmOpenRead or fmShareDenyNone);
  FileClose(H);
  Result := H <> INVALID_HANDLE_VALUE;
end;

CloseHandle/FileClose prüfen intern auf INVALID_HANDLE_VALUE, womit man das nicht selber zu machen braucht.


Will man aber wissen wer diese Dateien geöffnet hat, dann es gibt im Windows eine neuere API, wo Programme quasi zur Datei ihren Namen hinterlegen können.
Wenn sie es nicht machen, dann gibt es keinen offiziellen Weg, um da dran zu kommen. (Inoffizielle APIs und z.B. die Programme von SysInternals mal ausgenommen)

Zitat von MartinK:

das ich in irgendeiner meiner vielen Routinen eine Datei nicht wieder geschlossen habe

Es geht offenbar nicht darum, daß andere Prozesse die Datei offen halten, sondern das Programm selbst.

Kann man nicht einfach die geöffneten Dateien unter Computerverwaltung durchsehen?
Oder wird da nichts angezeigt?

Die Computerverwaltung zeigt Dateien an, welche über eine Netzwerkfreigabe geöffnet sind.

Wenn es nur darum geht den Fehler im eigenen Code zu finden, sollte es der Prozess Explorer und Konsorten doch tun.

Klingt aber als wenn du unsauber progranmiert hättest. Guck doch mal den Code durch: Nicht freigegeben FileStreams, nicht geschlossene Dateihandle usw...

Danke für die zahlreichen Tipps
ich denke ich werde mich zunächst mit den beiden MS Tools versuchen und anschl. Rückmeldung geben woran's lag und wie ich es rausgefunden habe.

vG Martin

Zwischenstand:
- Es handelt sich doch um nicht um eine "geöffnete Datei" ansich, sondern um einen "(Unter)Ordner" innerhalb Appdata/Roaming den meine Applikation scheinbar irgendwie blockiert.
Dieser Ordner kann nicht gelöscht/Renamed werden , was ich aber tun müsste (für eine Backup-Funktionalität).

- Ich bin mir ziemlich sicher dass ich keine "Bugs im Code an sich habe". Wie sollte ich auch einen Ordner "offen halten". Bei Ordnern gibt es ja kein "CloseFile", "free" etc.
Der Process-Explorer und Process Monitor von MS werden mir deswegen vermutlich auch nur wenig bei der Suche helfen

- Was ich jetzt noch getestet habe: Ich habe im Programm verwendete Komponenten die eine "Directory-Eigenschaft" die dies evtl. verursachen könnten, -> diese habe ich per Sourcecode bewusst auf einen anderen Ordner umgestellt.
und zwar bei allen TOpenDialog(InitialDir), TSaveDialog (InitialDir), TDirectoryListbox (Directory)
leider war es das auch (noch) nicht

Habt ihr noch Ideen was ich noch prüfen könnte ? Gibt es überhaupt noch weitere Komponenten die eine Directory Eigenschaft habe die mir jetzt nicht aufgefallen sind?

vG Martin