Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Problem mit CopyFile (https://www.delphipraxis.net/190146-problem-mit-copyfile.html)

hoika 4. Sep 2016 17:33

AW: Problem mit CopyFile
 
Hallo,
ein Virenscanner kann schon dafür sorgen,
dass das Programm abschmiert.

ConnorMcLeod 5. Sep 2016 11:43

AW: Problem mit CopyFile
 
Da gibts dann noch ShFileOperation als Alternative.

Metschu 5. Sep 2016 11:45

AW: Problem mit CopyFile
 
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 5. Sep 2016 11:59

AW: Problem mit CopyFile
 
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 5. Sep 2016 12:59

AW: Problem mit CopyFile
 
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 5. Sep 2016 13:31

AW: Problem mit CopyFile
 
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 5. Sep 2016 13:46

AW: Problem mit CopyFile
 
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 5. Sep 2016 13:54

AW: Problem mit CopyFile
 
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 5. Sep 2016 13:55

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

Assarbad 5. Sep 2016 14:01

AW: Problem mit CopyFile
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:11 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz