AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Problem mit CopyFile

Ein Thema von Berni68 · begonnen am 4. Sep 2016 · letzter Beitrag vom 6. Sep 2016
Antwort Antwort
Seite 2 von 4     12 34      
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.276 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Problem mit CopyFile

  Alt 4. Sep 2016, 18:33
Hallo,
ein Virenscanner kann schon dafür sorgen,
dass das Programm abschmiert.
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von ConnorMcLeod
ConnorMcLeod

Registriert seit: 13. Okt 2010
Ort: Bayern
490 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 12:43
Da gibts dann noch ShFileOperation als Alternative.
Nr.1 Delphi-Tool: [F7]
  Mit Zitat antworten Zitat
Metschu

Registriert seit: 31. Dez 2006
151 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#13

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 12:45
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.
Torsten
Ich kam, sah und alles Funktionierte.
Dann klingelte mein Wecker...
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#14

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 12:59
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.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#15

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 13:59
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.

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.

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.

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.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.625 Beiträge
 
Delphi 12 Athens
 
#16

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 14:31
Mich würde noch interessieren was diese mysteriöse Funktion `ForceDirectories` macht.
Moin Olli, da kann ich weiterhelfen: http://docwiki.embarcadero.com/Libra...rceDirectories
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#17

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 14:46
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?!
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
nahpets
(Gast)

n/a Beiträge
 
#18

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 14:54
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.
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#19

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 14:55
Was Assarbad meint: Der Rückgabewert von ForceDirectories sollte geprüft und eine entsprechende Fehlermeldung ausgegeben werden, wenn sie fehlschlägt.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#20

AW: Problem mit CopyFile

  Alt 5. Sep 2016, 15:01
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.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 4     12 34      

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:25 Uhr.
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