AW: DeleteFile und die Datei ist immer noch da
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?
|
AW: DeleteFile und die Datei ist immer noch da
Zitat:
Delphi-Quellcode:
if not DeleteFile(s) then
begin ShowMessage('Datei konnte nicht gelöscht werden !'); Abort; end; Zitat:
|
AW: DeleteFile und die Datei ist immer noch da
Zitat:
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:
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. |
AW: DeleteFile und die Datei ist immer noch da
Liste der Anhänge anzeigen (Anzahl: 1)
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. :stupid: Anhang 45860 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 DeleteFile folgender Code falsch
Delphi-Quellcode:
Denn GetLastError kann auch ungleich 0 sein, selbst wenn alles erfogreich war
SetLastError(0);
DeleteFile(...); DeleteFile(...); DeleteFile(...); DeleteFile(...); if GetLastError <> 0 then ZeigeFehler(GetLastError); 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:
GetLastError wird nur ausgewertet, wenn mindestens ein Result FALSE sagte
B := DeleteFile(...);
B := B and DeleteFile(...); B := B and DeleteFile(...); B := B and DeleteFile(...); if not B then ZeigeFehler(GetLastError); 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. |
AW: DeleteFile und die Datei ist immer noch da
Ja du hast im Prinzip das wiederholt was ich schong gesagt hatte:
Zitat:
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:
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. |
AW: DeleteFile und die Datei ist immer noch da
Delphi-Quellcode:
Auch da muß das Ergebnis nicht stimmen, selbst wenn es nur eine Funktion ist.
SetLastError(0);
DeleteFile(...); if GetLastError <> 0 then ZeigeFehler(GetLastError); Es steht ja extra so in der Hilfe Zitat:
Siehe das Beispiel mit dem CopyFile: Das Kopieren war erfolgreich, aber intern gab es einen "unbedeutenden" Fehler. |
AW: DeleteFile und die Datei ist immer noch da
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 |
AW: DeleteFile und die Datei ist immer noch da
Zacherl hat schon recht. Ich würde auch auf ein offenes Handle tippen.
Zitat:
Normalerweise ist das vermeintliche sofortige Löschen einer Datei ja erstmal nichts anders als das Setzen von DeleteFile in FILE_DISPOSITION_INFORMATION mittels ZwSetInformationFile(hFile, ..., FileDispositionInformation, ...). Die Datei wird also zum Löschen vorgemerkt. Und du darfst dir die Win32-API DeleteFile 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:
Zitat:
Übrigens könntest du als Admin mit dem aktivierten Backupprivileg doch Glück haben. Aber ist nur so eine Idee, hab's nicht getestet. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:50 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