AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi DeleteFile und die Datei ist immer noch da

DeleteFile und die Datei ist immer noch da

Ein Thema von fs999 · begonnen am 30. Aug 2016 · letzter Beitrag vom 22. Sep 2016
Antwort Antwort
Seite 2 von 2     12
Erdbär
(Gast)

n/a Beiträge
 
#11

AW: DeleteFile und die Datei ist immer noch da

  Alt 31. Aug 2016, 12:57
Wie wäre es, wenn Du vor dem Hochladen der (neuen) Datei die (alte) Datei auf dem Server löschen lassen würdest und dann ein paar Sekunden warten würdest, damit der Server den Löschbefehl auch ausführen kann?
  Mit Zitat antworten Zitat
Benutzerbild von fs999
fs999

Registriert seit: 4. Dez 2006
Ort: Luxembourg
46 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: DeleteFile und die Datei ist immer noch da

  Alt 31. Aug 2016, 15:07
Ich wollte wissen, ob du eine Fehlerbehandlung in deinem Code hast. Zum Beispiel ob der Rückgabewert von 8i]delteFile[/i] geprüft wird und wenn es fehlschlägt, was als Fehlermeldung ausgegeben wird.
Ja.
Delphi-Quellcode:
if not DeleteFile(s) then
begin
  ShowMessage('Datei konnte nicht gelöscht werden !');
  Abort;
end;
Wie wäre es, wenn Du vor dem Hochladen der (neuen) Datei die (alte) Datei auf dem Server löschen lassen würdest und dann ein paar Sekunden warten würdest, damit der Server den Löschbefehl auch ausführen kann?
Welchen Server ? Die Datei wird in C:\ProgramData\xxx unterlegt.
  Mit Zitat antworten Zitat
Pixel

Registriert seit: 23. Aug 2016
26 Beiträge
 
#13

AW: DeleteFile und die Datei ist immer noch da

  Alt 21. Sep 2016, 14:55
Ähhhhh, FALSCH und FALSCH.

siehe MSDN-Library durchsuchenDeleteFile

Delphi-Quellcode:
procedure checkErrorDeleteFile(const path : string);
begin
  //SetLastError(0); // das heißt LAST-Error und nicht THIS-Error
  is not DeleteFile(PChar(path)) then // rate mal, warum der Wert von GetLASTError nur "definitert" ist, wenn es einen Fehler gab :roll:
    //ShowMessage(IntToStr(GetLastError)); //ShorMessage als Fehlerbehandlung?
    RaiseLastOSError; // aka raise Exception.Create(SysErrorMessage(GetLastError));
end;
Sorry, es gibt zwar viele Wege, um nach Rom zu kommen, aber man sollte niemals nach links gehn, wenn dort ein Schild "rechts" steht.

FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH


Ich glaube du hast GetLasterror/SetLastError nicht so ganz verstanden.

SetLastError(0) setzt nur den Fehler auf 0 (ERROR_SUCCESS). Das ist beim Debugging einer Fehlerbehandlung empfehlenswert und manchmal sogar notwendig, denn sonst kann man nicht zu 100% sagen ob der Fehler dem nächsten Befehl zugeordet ist.

GetLastError "nur definiert wenn es einen Fehler gab": Wenn es keinen Fehler gab, dann ist GetLastError 0 (ERROR_SUCCESS). Einen Wert bekommst du immer zurück und wenn alles gut ging, dann eben 0.

Zitat aus MSDN: https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx
Zitat:
That is because some functions call SetLastError with a zero when they succeed, wiping out the error code set by the most recently failed function.
Beispiel:

WriteFile(x,x,x,x,x); SetLastError(5) -> ERROR_ACCESS_DENIED
deletefile(x); SetLastError(0) -> ERROR_SUCCESS
GetLastError(); Ausgabe: 0

Wenn GetastError() jetzt 0 (ERROR_SUCCESS) zurückliefert, dann würde der Anfänger meinen beide Funktionen seien erfolgreich durchlaufen, wobei hier in dem Fall deletefile einfach den Fehlercode "5" von writefile mit "0" überschrieben hat-


Meine Funktion diente nur zum debugging und funktioniert wunderbar. Klar, das SetLastError() kann man auch weglassen und dann mit "is not deletefile()" arbeiten ich finde es eben anders besser, es könnte ja rein theoretisch sein, dass LastError schon einen Fehlerwert hat bevor deletefile aufgerufen wird und dann obwohl deletefile fehlschlägt lasterror nicht updated/überschrieben wird. Ist zwar praktisch so gut wie unmöglich aber allein dass es theoretisch so sein könnte hält mich davon ab bei sowas SetLastError(0) wegzulassen.

"Sorry, es gibt zwar viele Wege, um nach Rom zu kommen, aber man sollte niemals nach links gehn, wenn dort ein Schild "rechts" steht." Vor allem sollte man erst mal das richtige Schild suchen https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx und dann das Schild lesen bevor man los geht.

Geändert von Pixel (21. Sep 2016 um 15:34 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
40.460 Beiträge
 
Delphi 11 Alexandria
 
#14

AW: DeleteFile und die Datei ist immer noch da

  Alt 21. Sep 2016, 15:34
GetLastError gibt per Definition den letzten Fehler zurück,
aber da ständig irgenwelche Trottel mit SetLastError rumpfuschen und solche arbeiten auch bei Microsoft selber, stimmt das eben nicht immer.

Und mit SetLastError setzt man einen "neuen" Fehlercode, womit er dann der Letzte ist.

PS: 0 ist auch ein "Fehler Code", weswegen es auch einen beliebten Fehler in der Fehlerbehandlung gibt.
operation_completed_succesfully_error_funny_error_messages-s355x201-95216-580.jpg



Auch kann eine Unterfunktion, einen Fehler auslösen, selbst wenn die Hauptfunktion letztendlich korrekt durchlief.

Beispiel Anhand einer imaginären Dateikopierfunktion ala CopyFile:
Zuerst mal mit GetMem großen Speicher anfragen,
wenn nicht genug RAM frei, dann nochmal nach kleinerem Speicher fragen (das ging jetzt)
dann über dem Speicher kopieren und fertig.

GetMem sagte nun einmal Fehler, womit der Fehlercode gesetzt wurde
aber CopyFile sagt dennoch TRUE, da ja doch noch kopiert werden konnte.
Vorher SetLastError(0) würde also garnichts bringen.


Somit ist, laut MSDN für MSDN-Library durchsuchenDeleteFile folgender Code falsch
Delphi-Quellcode:
SetLastError(0);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
if GetLastError <> 0 then
  ZeigeFehler(GetLastError);
Denn GetLastError kann auch ungleich 0 sein, selbst wenn alles erfogreich war
und wenn DeleteFile oder eine Unterfunktion intern auch mit SetLastError(0) rumpfuscht, dann würde ein nachfolgendes DeleteFile den Fehler des Vorherrigen verdecken.

Delphi-Quellcode:
B := DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
if not B then
  ZeigeFehler(GetLastError);
GetLastError wird nur ausgewertet, wenn mindestens ein Result FALSE sagte
und nachfolgende DeleteFile werden nicht aufgerufen, wenn vorher was schief lief, denn DeleteFile sagt in der Doku nicht, dass vorherriger ErrorCode erhalten bleibt, im Erfolgsfall.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list

Geändert von himitsu (21. Sep 2016 um 15:54 Uhr)
  Mit Zitat antworten Zitat
Pixel

Registriert seit: 23. Aug 2016
26 Beiträge
 
#15

AW: DeleteFile und die Datei ist immer noch da

  Alt 21. Sep 2016, 16:41
Ja du hast im Prinzip das wiederholt was ich schong gesagt hatte:

Zitat:
SetLastError(0);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
if GetLastError <> 0 then
ZeigeFehler(GetLastError);
In dem Fall bringt SetLastError(0) LOGISCHERWEISE rein gar nichts. Das ist das gleiche wie bei meinem Beispiel wo ich erst WriteFile() und dann DeleteFile() aufrufe.

Es macht keinen Sinn SetLastError auf 0 zu setzen wenn man daraufhin mehrere Funktionen called und am Ende dann den LastError prüft. Jeder DeleteFile call ruft schließlich SetLastError() auf und somit ist das Ergebnis von GetLastError der Fehlercode des letzten calls von DeleteFile.

Fazit: Praktisch ist es unnötig gewesen von mir SetLastError(0) aufzurufen, da man nur eine einzelne Funktion aufruft die intern SetLasterror() called und somit LastError sowieso auf diese bezogen ist. Deine Aussage ist dennoch etwas widersprüchlich.

Zitat:
GetLastError gibt per Definition den letzten Fehler zurück,
aber da ständig irgenwelche Trottel mit SetLastError rumpfuschen und solche arbeiten auch bei Microsoft selber, stimmt das eben nicht immer.
GetLastError gibt per Definition zwar den letzten Fehler zurück, nur ist 0 "ERROR_SUCCESS" eben auch als Fehler definiert, wie du ja mittlerweile auch erkannt hast.

Die prüfung mit "is not DeleteFile" halte ich daher für einen nicht notwendigen Indikator zum Aufruf von GetLastError da SetLastError eben auf 0 gesetzt wird wenn die Funktion Erfolg hatte.

OP wollte schließlich den Fehler von DeleteFile und eine Ausgabe, die bekommt er mit meinem Code immer und wenn 0 zurückkommt, dann weiß er dass alles gut gegangen ist.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
40.460 Beiträge
 
Delphi 11 Alexandria
 
#16

AW: DeleteFile und die Datei ist immer noch da

  Alt 21. Sep 2016, 17:12
Delphi-Quellcode:
SetLastError(0);
DeleteFile(...);
if GetLastError <> 0 then
  ZeigeFehler(GetLastError);
Auch da muß das Ergebnis nicht stimmen, selbst wenn es nur eine Funktion ist.

Es steht ja extra so in der Hilfe
Zitat:
Result=True wenn erfolgreich
und False wenn nicht. Für genauen Fehler dann bei GetLastError nachgucken.
Für Result=True ist LastError halt selten definiert, da es dann eben keinen Fehler gab ... soll heißen, es kann sein, dass DeleteFile den LastError unverändert lies, oder jetzt was Anderes drin steht.
Siehe das Beispiel mit dem CopyFile: Das Kopieren war erfolgreich, aber intern gab es einen "unbedeutenden" Fehler.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#17

AW: DeleteFile und die Datei ist immer noch da

  Alt 21. Sep 2016, 17:49
Es gehörte mal zum "guten Ton" mit SetLastError die Fehlernummer vor zu belegen, damit man sicher war gegen Welchen Wert eine Fehlerprüfung vorgenommen werden konnte.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

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

AW: DeleteFile und die Datei ist immer noch da

  Alt 22. Sep 2016, 17:25
Zacherl hat schon recht. Ich würde auch auf ein offenes Handle tippen.

Erst wenn ich das Programm schließe verschwindet die Datei.
Was komisch ist DeleteFile('name') gibt True zurück und TFileStream.Create('name', fmCreate) meldet kein Fehler.
Schonmal im Process Explorer oder gar mit ProcMon nachgeschaut? Da schwirrt mit ziemlicher Sicherheit noch irgendwo ein Handle auf die Datei rum. Ich behaupte ja nicht, daß es in deinem Prozeß ist, aber der Process Explorer könnte dies ohne weiteres aufdecken, so oder so.

Normalerweise ist das vermeintliche sofortige Löschen einer Datei ja erstmal nichts anders als das Setzen von DeleteFile in MSDN-Library durchsuchenFILE_DISPOSITION_INFORMATION mittels MSDN-Library durchsuchenZwSetInformationFile(hFile, ..., FileDispositionInformation, ...). Die Datei wird also zum Löschen vorgemerkt.

Und du darfst dir die Win32-API MSDN-Library durchsuchenDeleteFile als Hülle für den oben genannten Mechanismus vorstellen. Wenn du also eine Datei zum Löschen markierst, wird diese weiterexistieren, bis das letzte Handle weg ist:

Zitat:
A file marked for deletion is not actually deleted until all open handles for the file object have been closed and the link count for the file is zero.
Auf unixartigen Systemen ist dies übrigens ganz ähnlich, auch wenn die Datei aus dem Ursprungsverzeichnis sofort verschwindet. Mithilfe des /proc-Dateisystems kann man die Datei "wiederherstellen" indem man sie aus /proc wieder "herauskopiert", siehe hier.

Wenn das Programm läuft kann ich nicht diese Datei öffnen, sogar als Administrator komme ich nicht in den Eigenschaften an die Security ran...
Ich empfehle die Lektüre von MSDN-Library durchsuchenCreateFile und dort im Besonderen von dwShareMode

Übrigens könntest du als Admin mit dem aktivierten Backupprivileg doch Glück haben. Aber ist nur so eine Idee, hab's nicht getestet.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 10:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf