Problem mit CopyFile

[nahpets]

Definiere bitte kurz: "Programm ist abgestürzt"

Das Programm ist "einfach" weg?
Keine Meldung bezüglich Zugriffsverletzungen ...

Einfach so aus Taskleiste, Liste der laufenden Programm ... verschwunden?

Habe vor Jahren auch mal auf Systemen mit TrendMicro gearbeitet, weiß aber nicht mehr, ob und wie da protokolliert wird.

Gibt es da irgendwelche Logfiles ... in denen zum Zeitpunkt des Programmabsturzes irgendwas protokolliert wird?

Insgesammt Deine Routine "aussagefreudiger" machen:
(ungetestet hingeschrieben - als Idee)

Delphi-Quellcode:

procedure TJobServerForm.VerschiebePdf;
var
  files: TStrings;
  i:integer;
  ziel, zielpfad: string;
  ok: boolean;
  LogFile : String; 
begin
  LogFile := Format('c:\TJobServerForm.VerschiebePdf.%s.log',[AnsiReplaceText(DateTimeToStr(Now),':','.')]);
  memo.Lines.Add(Format('Starte Routine: TJobServerForm.VerschiebePdf - %s',[DateTimeToStr(Now)]));
  memo.Lines.SaveToFile(LogFile);
  files := TStringList.Create;
  memo.Lines.Add(Format('vor GetFilesMatchInPath(%s, %s, files, false)',[LokalPdfDir,'*.pdf']));
  memo.Lines.SaveToFile(LogFile);
  GetFilesMatchInPath(LokalPdfDir, '*.pdf', files, false);
  memo.Lines.Add('gefundenen Dateien:');
  memo.Lines.Add(files.Text);
  memo.Lines.Add(Format('hinter GetFilesMatchInPath(%s, %s, files, false)',[LokalPdfDir,'*.pdf']));
  memo.Lines.SaveToFile(LogFile);
  try
    for i := 0 to files.Count - 1 do begin
      try
        memo.Lines.Add(Format('%d/%d %s',[i+1,files.Count,files[i]]));
        zielpfad := WithBackSlash(PdfDir) + ExportSubDirFromFileName(files[i]);
        memo.Lines.Add(Format('Zielpfad: %s',[ZielPfad]));
        if not DirectoryExists(zielpfad) then begin
          memo.Lines.Add(Format('ForceDirectories: %s',[ZielPfad]));
          ForceDirectories(zielpfad);
        end;
        ziel := zielpfad + ExtractFileName(files[i]);
        memo.Lines.Add(Format('Ziel: %s',[Ziel]));
        memo.Lines.Add(Format('vor CopyFile(%s,%s, false)',[files[i],ziel]));
        memo.Lines.SaveToFile(LogFile);
// ShowMessage('#');  // ist zwar schön
// ShowMessage(Files[i]);  // dürfte aber aussagefähiger sein ;-)
        ok := CopyFile(PChar(files[i]), PChar(ziel), false);
        memo.Lines.Add(Format('hinter CopyFile(%s,%s, false)',[files[i],ziel]));
        memo.Lines.SaveToFile(LogFile);
        if ok then begin
          memo.Lines.Add(Format('vor DeleteFile: %s',[files[i]]));
          memo.Lines.SaveToFile(LogFile);
          if DeleteFile(files[i]) then begin
            memo.Lines.Add(Format('erfolgreich: DeleteFile: %s',[files[i]]));
          end else begin
            memo.Lines.Add(Format('nicht erfolgreich: DeleteFile: %s',[files[i]]));
          end;
          memo.Lines.Add(Format('hinter DeleteFile: %s',[files[i]]));
          memo.Lines.SaveToFile(LogFile);
        end;
      except
        on e : Exception do begin
          memo.Lines.Add(Format('Exception bei Datei: %s',[files[i]]));
          memo.Lines.Add(Format('Fehlermeldung: %s',[e.Message]));
          memo.Lines.SaveToFile(LogFile);
          RaiseLastOSError;
        end;
      end;
    end;
  finally
    files.Free;
  end;
  memo.Lines.Add(Format('Beende Routine: TJobServerForm.VerschiebePdf - %s',[DateTimeToStr(Now)]));
  memo.Lines.SaveToFile(LogFile);
end;

Lassen sich anhand der so erstellten Logfiles irgendwelche Systematiken erkennen?

Programmabsturz beim zweiten Aufruf immer bei der

• ersten Datei?
• gleichen Datei?
• einem bestimmten Pfad?

Das memo.Lines.SaveToFile(LogFile); alle Nas' lang aufzurufen, ist sicherlich nicht performant, aber man hat so die Chance bei beliebigen Zwischenschritten die Meldungen auf die Platte zu bekommen, da bei 'nem Absturz beim folgenden Befehl, die Infos aus dem Memo schon weggeschrieben sind.

Alternative 'ne Loggingfunktion nehmen, die die Ausgabedatei vor jedem Schreibvorgang öffnet und nach jedem Schreibvorgang schließt.

[Berni68]

Hallo nahpets,

abgestürzt heisst: "Programm ist einfach weg!"
Keine Meldungen.
Meine Routinen waren/sind schon aussagefreudiger.
Ich habe hier nur das ganze 'etwas' komprimiert und auf das wesentliche reduziert.

Ich kann, nach etlichen Tests, sicher sagen, dass der Absturz in der Zeile
CopyFile(PChar(files[i]), PChar(ziel), false);
passiert, mit oder ohne Zuweisung des Ergebnisses an die Boolsche Variable 'ok'
Ich kann sicher sagen, dass die übergebenen Dateinamen korrekt sind.
Es ist fast immer die 2. pdf bei der das Programm abschmiert. Einmal von vielen Tests war es erst die 3. pdf
Wenn das Programm dann neu gestartet wird, wird die Datei, bei der es zuvor abgestürzt ist (identische Pfad- und Dateinaman wie zuvor)
korrekt kopiert und gelöscht, und stürzt dann wiederum bei der nächsten pdf ab.
D.h. Wenn z.B. 13 pdf-Dateien im Verzeichnis sind, kann man durch 13 maliges Starten des Programmes die Aufgabe korrekt erledigen.
Ich habe auch schon mit Verzögerungen a la
sleep(2000);
oder langen Wartezeiten bei
ShowMessage('#');
rumprobiert, um Timingprobleme zu umgehen,
hat aber den Absturz (praktisch immer bei der 2. pdf) nicht verhindert.

[nahpets]

Befremdlich das Ganze.

Es gibt auch noch function MoveFile(lpExistingFileName, lpNewFileName: PChar): BOOL; Wäre das mal eine Testalternative?

Dadurch könnte die Kombination von CopyFile und DeleteFile (eventuell) entfallen.

Wo hast Du ShowMessage bzw. Sleep(2000) hingemacht?

Zwischen CopyFile und DeleteFile?

Weiß nicht, wie CopyFile arbeitet. Läuft das Kopieren im Hintergrund oder wartet das Programm, bis CopyFile fertig ist und löscht erst dann mit DeleteFile?

Eventuell trennst Du mal CopyFile und DeleteFile.

Aus der momentanen Routine DeleteFile rausnehmen und erst am Ende in 'ner eigenen Schleife aufrufen?

Delphi-Quellcode:

procedure TJobServerForm.VerschiebePdf;
var
  files: TStrings;
  i:integer;
  ziel, zielpfad: string;
  ok: boolean;
begin
  files := TStringList.Create;
  GetFilesMatchInPath(LokalPdfDir, '*.pdf', files, false);
  try
    for i := files.Count - 1 DownTo 0 do begin
      try
        memo.Lines.Add(IntToStr(i+1) + '/' + IntToStr(files.Count)+ ' ' + files[i]);
        zielpfad: = WithBackSlash(PdfDir) + ExportSubDirFromFileName(files[i]);
        if not DirectoryExists(zielpfad) then ForceDirectories(zielpfad);
        ziel := zielpfad + ExtractFileName(files[i]);
        ok := CopyFile(PChar(files[i]), PChar(ziel), false);
      except
        RaiseLastOSError;
      end;
    end;
    for i := files.Count - 1 DownTo 0 do begin
      try
        zielpfad := WithBackSlash(PdfDir) + ExportSubDirFromFileName(files[i]);
        ziel := zielpfad + ExtractFileName(files[i]);
        if FileExists(Ziel) then files.Delete(i);
      except
        RaiseLastOSError;
      end;
    end;
    If files.Count > 0 then begin
      ShowMessage('Es konnten nicht alle Dateien kopiert und gelöscht werden!' + #13#13 + Files.Text);
    end;
  finally
    files.Free;
  end;
end;

[Berni68]

Hallo nahpets,

ich habe testweise bereits das DeleteFile schon ganz weggelassen.
Ohne Erfolg.
CopyFile, wie oben erwähnt, durch einen TMemoryStream mit LOKAL lesen und ENTFERNT schreiben ersetzt.
Immer das gleiche, bei der 2. pdf ist das Programm weg.

Auch noch interessant:
Wenn ich das kopieren auf einen anderen PC umleite funktioniert alles problemlos.
Es muss also was mit dem Zielrechner zu tun haben.
Morgen werde ich veranlassen daß der Virenscanner temporär abgestellt wird (zumindest für pdf's) (hab dazu leider nicht das erforderliche Passwort, macht eine Fremdfirma...)
Gleichzeitig lagere ich das kopieren mal aus und erstelle hierzu lediglich eine Batch-Datei (XCOPY ....), die dann von Hand angestossen werden soll/muss.
Bin gespannt was dann passiert.

Allerdings kann ich mir nicht erklären wie ein entfernter Rechner das lokale programm abschiessen kann.
Ich hätte eigentlich erwartet, daß das Kopieren lediglich fehlschlägt, was dann aber mit dem Rückgabewert False entsprechend behandelt werden kann

[nahpets]

Zitat von Berni68:

Allerdings kann ich mir nicht erklären wie ein entfernter Rechner das lokale programm abschiessen kann.

Beim Kopieren scheint etwas zu passieren, mit dem die API-Funktion CopyFile von Windows nicht zurecht kommt und sich da "final" verabschiedet, so dass das ganze Programm "weg" ist. "Schuld" ist da schon der Rechner, auf dem die Kopierakton läuft, da er mit einem "unbekannten Verhalten der Gegenseite" nicht zurecht kommt.

Die Idee mit der Batch-Datei und XCopy ist ok.
Wenn das "händisch" funktioniert, könntest Du die Batchdatei ja auch erstellen und dann aus Deinem Programm per ShellExecute aufrufen, dann muss der Anwender nix "zu Fuß" machen und kann dann auch nichts vergessen.
Oder die XCopys direkt aus dem Programm per ShellExecute aufrufen.

Statt XCopy wäre es dann aber auch eine Überlegung wert "Move" zu verwenden, dann musst Du dich nicht um das Löschen der Quelldatei kümmern.
Und es kann keine Probleme bei der Synchronisation zwischen dem Kopieren und dem Löschen geben.
Desweiteren: Bei Dateien, die nach dem Aufruf von Move noch "übrig" sind, weiß man, dass da was schief ging und man löscht nicht versehentlich Dateien, bei denen der Kopiervorgang (warum auch immer) gescheitert ist.

Schöner wär's ja schon, wenn's denn 'ne vernünftige Begründung für dieses "seltsame" Verhalten gäbe.