Problem mit CopyFile

[Berni68]

Hallo zusammen,

ein Programm, das nunmehr ca. 3 Jahre einwandfrei funktioniert hat, stürzt jetzt reproduzierbar ab.
In einer Prozedur werden lokale Dateien auf den Server kopiert und lokal gelöscht.
Ziel sieht so aus:
\\Server\pfad\unterverzeichnis\datei_i.pdf

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:=0 to files.Count-1 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]);
ShowMessage('#');
        ok:= CopyFile(PChar(files[i]), PChar(ziel), false);
        if ok then DeleteFile(files[i]);
      except
        RaiseLastOSError;
      end;
    end;
  finally
    files.Free;
  end;  
end;

Die Schleife wird das erste mal korrekt durchlaufen (Datei wird korrekt kopiert und lokal gelöscht), beim zweiten mal immer Absturz,
und zwar genau bei der Anweisung nach ShowMessage('#');
except wird nicht durchlaufen.
Es sieht so aus als ob das nur bei .pdf-Dateien passiert, da an anderer Stelle mit ähnichem Code nicht pdf dateien problemlos verarbeitet werden.
Da sich an dem Gesamtsystem nichts verändert hat ausser Betriebssystem und Virenscanner Updates sollte es wohl daran liegen.
Der Virenscanner ist TrendMicro
Angenommen es liegt am Virenscanner (meine Vermutung, die aber erst morgen durch Abschalten überprüft werden kann) nun die Frage:
Was kann man tun, ausser den Virenscanner für .pdf zu deaktivieren?
(CopyFile durch TMemoryStream Load / Save zu ersetzten, hab ich probiert: bringt nichts, identisches Ergebnis)
(Ich gehe davon aus, dass man den Virenscanner nicht dauerhaft deaktivieren wird)

[nahpets]

Wie heißt denn die Fehlermeldung?

Delphi-Quellcode:

except
  on e : Exception do begin
    ShowMessage(e.Message);
    // Aus der Doku: Raises an exception for the last occurring OS 
    // or system library error.
    RaiseLastOsError; // Ist denn überhaupt so ein Fehler aufgetreten?
  end;
end;

Wird Except definitiv nicht durchlaufen?
Per Debugger und Breakpoint überprüft?

[Berni68]

Per Debugger und Breakpoint nicht überprüft, da das Programm bei einer Firma läuft in der ich nicht mehr arbeite.
D.h. Ich programmiere zuhause, übermittle die exe und lasse mir die Ergebnisse berichten.
Ich habe aber auch schon
ShowMessage('Exception');
direkt nach except eingefügt.
Die Meldung wird nie angezeigt, Programm ist abgestürzt.
In meiner Umgebung zuhause läuft alles problemlos. Habe allerdings auch keinen TrendMicro.

[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

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Berni68 (Beitrag 1346714)

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.

[himitsu]

Zitat:

Zitat von Berni68 (Beitrag 1346693)

das nunmehr ca. 3 Jahre einwandfrei funktioniert hat,

Delphi-Quellcode:

procedure TJobServerForm.VerschiebePdf;
        ok:= CopyFile(PChar(files[i]), PChar(ziel), false);
        if ok then DeleteFile(files[i]);
      except
        RaiseLastOSError;
      end;

Im Fehlerfall hat das noch niemals einwandfrei funktioniert, da diese APIs praktisch niemals eine Exception werfen, sondern nur einen Fehlercode liefern (Result=False + GetLastError).

Warum eigentlich nicht MoveFile?

Delphi-Quellcode:

if not EineWinAPI(...) then
  RaiseLastError;

Also ja, es kann sein, dass der VirenScanner eine neue Datei noch geöffnet hat, wenn du zugreifen willst.
Genauso kann z.B. auch ein Explorer-Plugin der Grund sein.
Im Explorer werden doch Dateiinformationen angezeigt ... dafür öffnet das Plugin die Dateien, um das auszulesen. (da macht Adobe gern mal Problemchen)

[Berni68]

Hallo himitsu,

da hast du recht.
Tatsächlich ist die ursprüngliche Variante auch:

if CopyFile(PChar(files[i]), PChar(ziel), false) then DeleteFile(files[i]);

Wenn es dann schief ging, warum auch immer, z.B. die Zieldatei ist geöffnet, wird die Datei nicht gelöscht.
Beim nächsten Durchlauf des Programmes ca. 5min später wird es dann wieder probiert usw.
Hat soweit eingentlich funktioniert.

Ich werde es auf jeden Fall auch mit MoveFile probieren.

Allerdings funktionierte auch der Versuch in der ich NUR kopiert habe NICHT.
Also ausschließich:

CopyFile(PChar(files[i]), PChar(ziel), false);

Ohne Delete.
Auch hier immer Absturz bei der 2. pdf
Da greife ich doch auf die neue Datei garnicht zu? Oder?

[hoika]

Hallo,
ein Virenscanner kann schon dafür sorgen,
dass das Programm abschmiert.

[ConnorMcLeod]

Da gibts dann noch ShFileOperation als Alternative.

[Metschu]

Wenn der Virenscanner ein Programm Blockiert / Beendet, speichert er das dann nicht in der Historie oder so ab?

So müsste man es doch auch nachvollziehen können.

[Luckie]

Delphi-Quellcode:

if CopyFile(..) <> 0 then
  RaiseLastOSError

Gibt das eine gescheite Fehlermeldung?

Aber so ganz glaub eich nicht, dass es an CopyFile liegt. Wenn sich ein Programm einfach so beendet, dann geht da sehr viel mehr schief als so ein banaler API Funktionsaufruf wie CopyFile.

[Assarbad]

Zitat:

Zitat von Berni68 (Beitrag 1346693)

Die Schleife wird das erste mal korrekt durchlaufen (Datei wird korrekt kopiert und lokal gelöscht), beim zweiten mal immer Absturz,
und zwar genau bei der Anweisung nach ShowMessage('#');
except wird nicht durchlaufen.

Das weist ja eher darauf hin, daß du dir etwas beim ersten Durchlauf zerschießt.

Warum? Weil du behauptest, daß es beim ersten Mal funktioniert. Für die Serverseite oder das lokale Betriebssystem ist aber "das erste Mal" schon beim zweiten Test deines Programms nicht mehr das erste Mal! Ein AV-Filter könnte natürlich infrage kommen, da er bspw. auf Prozeßebene agieren könnte. Dann wäre aber das Durchlassen der ersten Datei eine Sicherheitslücke und ein solcher Scanner sollte gemieden werden.

Der Vollständigkeit halber: ich arbeite seit nunmehr zehn Jahren bei einem AV-Hersteller und bin selbst in der Entwicklung und Wartung des Dateisystemfiltertreibers tätig. Es handelt sich dabei nicht um Trend Micro.

Zitat:

Zitat von Berni68 (Beitrag 1346693)

Es sieht so aus als ob das nur bei .pdf-Dateien passiert, da an anderer Stelle mit ähnichem Code nicht pdf dateien problemlos verarbeitet werden.

Und mit gleichem Code? Parametrisiere doch einmal deine Funktion und übergib die Maske der zu kopierenden Dateiendungen. Es interessiert für das Debuggen nämlich nicht, ob es mit ähnlichem Code funktioniert, sondern nur ob es mit gleichem Code funktioniert. Abgesehen davon erlaubt dir die Parametrisierung aus zwei Funktionen mglw. eine zu machen.

Zitat:

Zitat von Berni68 (Beitrag 1346693)

Was kann man tun, ausser den Virenscanner für .pdf zu deaktivieren?

Anderen AV-Scanner einsetzen? Ernsthaft, es gibt kaum etwas was du im Usermode machen kannst, was den Scanner jucken würde. Üblicherweise wird schon das Öffnen der Datei abgefangen. Zugegeben, bei CopyFile siehst du davon nix, aber intern passiert da dennoch ein CreateFile usw.

In einigen Fällen wird auch das Schließen der Datei abgefangen. Kommt aber auf das exakte Szenario an.

Übrigens würde dir jeder normale AV-Scanner ein "Zugriff verweigert" liefern, was noch immer keinen Absturz nach sich zöge, es sei denn du reagiertest darauf nicht adäquat.

Zitat:

Zitat von hoika (Beitrag 1346744)

Hallo,
ein Virenscanner kann schon dafür sorgen,
dass das Programm abschmiert.

Das sind aber schon sehr grenzwertige Bedingungen, die dazu erfüllt sein müssen. Zumeist würde ich dann auch eine Zeitüberschreitung oder ähnliches erwarten (bspw. weil der Scan länger dauert). Da wäre dann auch interessant ob der lokale Scanner den Scan erledigt oder ob die Serverseite das macht. Da es nicht explizit angegeben ist, würde ich annehmen, daß es lokal gemacht wird - für jegliche Netzwerkpfade. Auch daß die Gegenseite etwas macht, womit CopyFile nicht klarkommt, ist unwahrscheinlich. Wenn die Gegenseite Windows oder Samba ist, würde ich es nahezu kategorisch ausschließen.

Mich würde noch interessieren was diese mysteriöse Funktion `ForceDirectories` macht.

Und dann noch was auf der Gegenseite läuft. Windows? Samba auf einem Linux?

Schonmal probiert das Programm mit procdump.exe zu starten und diesem aufzutragen bitte einen Minidump zu erstellen? Dann könnte man ja mindestens den Call-Stack sehen, auch wenn die Symbole von Delphi bekanntlich nicht kompatibel sind mit Microsoft's Debuggern.

[DeddyH]

Zitat:

Zitat von Assarbad (Beitrag 1346819)

Mich würde noch interessieren was diese mysteriöse Funktion `ForceDirectories` macht.

Moin Olli, da kann ich weiterhelfen: http://docwiki.embarcadero.com/Libra...rceDirectories

[Assarbad]

Zitat:

Zitat von DeddyH (Beitrag 1346824)

Zitat:

Zitat von Assarbad (Beitrag 1346819)

Mich würde noch interessieren was diese mysteriöse Funktion `ForceDirectories` macht.

Moin Olli, da kann ich weiterhelfen: http://docwiki.embarcadero.com/Libra...rceDirectories

Dank dir! Dann hätte ich ein Problem mit der Verwendung der Funktion seitens des Fragestellers. Ich zitiere mal:

Zitat:

ForceDirectories gibt den Wert True zurück, wenn es alle notwendigen Verzeichnisse erstellt hat, und False, wenn das Verzeichnis nicht erstellt werden konnte.

Fehlt da nicht was im uns präsentierten Code? Stichwort: defensive Softwareentwicklung?!

[nahpets]

Strenggenommen müsste man den Rückgabewert von ForceDirectories abfragen und entsprechend reagieren.

Sollte im konkreten Fall beim Aufruf der Funktion ein Fehler auftreten, dann kracht es halt irgendwo im späteren Ablauf der Routine.

Wirklich sauber ist es so, wie es ist nicht, aber auch ein Scheitern von ForceDirectories und die daraus resultierenden Probleme dürften nicht dazu führen, dass sich ein Programm einfach sang- und klanglos verabschiedet.

Da muss irgendwo noch was anderes gewaltig schiefgehen, was aber so aus der Ferne nicht zu erkennen ist.

[Luckie]

Was Assarbad meint: Der Rückgabewert von ForceDirectories sollte geprüft und eine entsprechende Fehlermeldung ausgegeben werden, wenn sie fehlschlägt.

[Assarbad]

Zitat:

Zitat von nahpets (Beitrag 1346830)

Wirklich sauber ist es so, wie es ist nicht, aber auch ein Scheitern von ForceDirectories und die daraus resultierenden Probleme dürften nicht dazu führen, dass sich ein Programm einfach sang- und klanglos verabschiedet.

Da muss irgendwo noch was anderes gewaltig schiefgehen, was aber so aus der Ferne nicht zu erkennen ist.

Du hast recht. Aber das Problem ist, daß man auf diese Weise nie das Problem finden wird.

Ich habe kein Delphi installiert, aber wie sähe es denn mit etwas in dieser Richtung hier aus?

Delphi-Quellcode:

function TJobServerForm.VerschiebeEntsprechendEndung(maske: String): Boolean;
var
  files: TStrings;
  i: Integer;
  ziel, zielpfad: String;
begin
  result := False;
  files:= TStringList.Create;
  GetFilesMatchInPath(LokalPdfDir, maske, files, false); // Rückgabewert?
  try
    for i:=0 to files.Count-1 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
        begin
          if not ForceDirectories(zielpfad) then
            RaiseLastOSError;
        end;
        ziel:= zielpfad + ExtractFileName(files[i]);
        if CopyFile(PChar(files[i]), PChar(ziel), false) then
        begin
          if not DeleteFile(files[i]) then
            RaiseLastOSError;
          result := True;
        end;
      except
        RaiseLastOSError;
      end;
    end;
  finally
    files.Free;
  end;
end;

Ich verstehe zwar noch immer nicht, wozu das "try ... except RaiseLastOSError; end;" gut sein soll, aber nen Grund wird es sicher haben.

[nahpets]

Nichts anderes wollte ich ausdrücken, wobei selbst das Nichtabfragen des Rückgabewertes und das Fehlen einer entsprechenden Reaktion darauf, nicht zu dem beschriebenen "Verabschieden des Programmes" führen dürfte.

[Assarbad]

Zitat:

Zitat von nahpets (Beitrag 1346834)

Nichts anderes wollte ich ausdrücken, wobei selbst das Nichtabfragen des Rückgabewertes und das Fehlen einer entsprechenden Reaktion darauf, nicht zu dem beschriebenen "Verabschieden des Programmes" führen dürfte.

Jupp, meine Argumentation war auch eher an den Fragesteller gerichtet, der nicht zu begreifen scheint, wie der Code zeigt, daß man Fehler nur durch disziplinierte und systematische Vorgehensweise finden kann.

Und ich stimme dir zu, ein stilles "Verabschieden" ist in der Tat ungewöhnlich. Ist es ketzerisch wenn ich jetzt den Fragesteller frage wie das ganze unter einem Debugger aussieht? :wink:

@Berni68: schonmal in der Windows-Ereignisanzeige nachgeschaut ob du da eine WER-Meldung siehst? Oder hast du möglicherweise WER abgeschaltet? Dann würde ich es auf jeden Fall mal aktivieren.

[Aviator]

Zitat:

Zitat von Assarbad (Beitrag 1346849)

Ist es ketzerisch wenn ich jetzt den Fragesteller frage wie das ganze unter einem Debugger aussieht? :wink:

Naja, er hat geschrieben, dass er das Programm für eine Firma in der er nicht mehr arbeitet programmiert. Von extern ... wo es wahrscheinlich schwierig sein wird mit einem Debugger zu arbeiten.

@TE: Wie verhält sich das Programm wenn du es auf einem anderen Rechner startest? Die Quelldateien und die Struktur kann man ja mal testweise dort anlegen.

[Assarbad]

Zitat:

Zitat von Aviator (Beitrag 1346855)

Zitat:

Zitat von Assarbad (Beitrag 1346849)

Ist es ketzerisch wenn ich jetzt den Fragesteller frage wie das ganze unter einem Debugger aussieht? :wink:

Naja, er hat geschrieben, dass er das Programm für eine Firma in der er nicht mehr arbeitet programmiert. Von extern ... wo es wahrscheinlich schwierig sein wird mit einem Debugger zu arbeiten.

Hmm, ich nahm nur an, wenn er es dort ursprünglich entwickelt hat, sollte ja möglicherweise auch in der Firma die entsprechende Umgebung existieren. Kann natürlich sein, daß er es quasi nebenbei entwickelt hat und seine Anstellung nichts mit Delphi zu tun hatte. Ansonsten sollte die Firma ja alles parat haben.

Bei aktuellem Informationsstand wird es jedenfalls schwierig da einen spezifischeren Rat zu geben als: systematisch debuggen und generell immer die Rückgabewerte von Funktionen zu überprüfen und entsprechend zu reagieren!

[Aviator]

Zitat:

Zitat von Assarbad (Beitrag 1346860)

Bei aktuellem Informationsstand wird es jedenfalls schwierig da einen spezifischeren Rat zu geben als: systematisch debuggen und generell immer die Rückgabewerte von Funktionen zu überprüfen und entsprechend zu reagieren!

Sehe ich auch so. Es wäre gut wenn sich der TE diesbezüglich nochmal äußern würde.

[Berni68]

Hallo zusammen,
das kocht hier ja ganz schön hoch!
Wie schon weiter oben gesagt hat das Programm ja auch zuverlässig fast 3 Jahre funktioniert.
Natürlich kann man jeden denkbaren Fehler im Vorfeld abfangen.
Habe ich aber nicht (Leistung gleich Arbeit pro Zeit:-D)
An dieser Stelle gab es nie Probleme (Probleme wären dadurch aufgefallen, dass das temp Verzeichnis nicht leer geworden wäre).
Heute wurde der lokale Virenscanner (also auf dem Jobserver) durch die Fremdfirma deaktiviert und, siehe da, alles funktioniert wieder so wie es soll.
Problem gelöst.

[Luckie]

Nun eigentlich nicht.

Rennfahrer: "In der Kurve verlieren wir immer zu viel Zeit."
Boxencrew: "OK. Problem gelöst. Jetzt nicht mehr. Wir haben die Bremsen ausgebaut."

[Berni68]

Rennfahrer: "In der Kurve verlieren wir immer zu viel Zeit."
Boxencrew: "Mach dir da mal keine Sorgen, auf den Geraden liegen wir derart weit vorne, dass der kleine Verlust in den Kurven keine Rolle spielt."

[Luckie]

Du hast meinen Vergleich nicht verstanden. Nur weil ein Programm nicht mit dem Virenscanner klar kommt, ihn für das gesamte System abzuschalten, ist keine sehr gute Idee. Da stellt sich die Frage, warum er überhaupt installiert ist.

[Berni68]

Dieser Pc arbeitet exklusiv als Jobserver für dieses Programm.
Keine Internetaktivitäten durch Benutzer.
Ich denke in diesem Fall ist die Deaktivierung des Virenscanners vertretbar.
Idealerweise sollte man den Pc aber für das Internet grundsätzlich sperren.

[Blup]

Die mir bekannten Virenscanner erlauben Ausnahmen für Verzeichnisse, Dateitypen und bestimmte Programme, deren Zugriffe nicht geprüft werden.
Ganz Abschalten ist die schlechteste Lösung.

[Assarbad]

Deinstallieren hilft. Aber wenn ihr das bewiesen habt, wäre es Zeit die Einstellungen des Scanners zu überprüfen (schießt der bspw. Programme ab die bestimmte Aktionen durchführen?), nach einer neueren Version der Software (nicht nur der Signaturen) zu suchen und wenn alles fehlschlägt das Problem an den Hersteller zu melden.

Gerade du als Softwareentwickler solltest ja wissen, daß man Fehler nur dann beheben kann, wenn sie einem bekannt sind.