Datei unerwarteterweise geöffnet - Löschen nicht möglich

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von kafffee.

    Datei unerwarteterweise geöffnet - Löschen nicht möglich

    Hallo :)

    ich hab ein kleines Problem, und zwar möchte ich programmatisch eine Datei löschen mit System.IO.File.Delete, bekomme aber den Fehler:

    System.IO.IOException
    HResult=0x80070020
    Nachricht = Der Prozess kann nicht auf die Datei "C:\Users\Me\AppData\Roaming\xyz\user.config" zugreifen, da sie von einem anderen Prozess verwendet wird.
    Quelle = mscorlib

    Gibt es vielleicht eine Möglichkeit herauszufinden, von welcher Stelle im Programm die Datei noch geöffnet ist, es kann gut sein dass es eine Async Function ist.

    Oder kann ich den File programmatisch vor dem Löschen einfach irgendwie explizit schliessen?

    @kafffee Hast Du eine Bild-Datei einer Bitmap-Instanz zugewiesen oder so was?
    Poste mal davon den Code.
    Öffne die Bild-Datei in einem Stream.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Laut Post#1 ist es eine config-Datei.
    Ist denn sicher, dass nur Dein Programm der Blockierer sein kann?
    Kannst Du denn die Datei testweise löschen, wenn Dein Programm beendet wurde?
    Ich kenne keinen Weg, zur Laufzeit den Blockierer oder gar die Blockierstelle rauszufinden, aber das heißt nix.

    Auch wenn das herzlich wenig zur aktuellen Frage beiträgt:
    Als ersten präventiven Gegenschritt kannst Du aber was an Deiner Projektstruktur machen: Isoliere alle Dateizugriffsfunktionen (wenn es viele sind) in einer Partial File, um die Übersicht zu verbessern, welche Verursacher infrage kommen. Als nächsten Schritt wäre auch eine Isolation in eine eigenen Klasse sinnvoll. Und dann kannst Du dort noch einfacher ein Logging einbauen, um die Ursache zu finden.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Wie aber RodFromGermany schrieb, nutze Streams. Am besten gleich mit einem using Statement. So ist dann sichergestellt, das die Datei wieder "frei" ist. Egal ob Bild- oder Text- oder WasAuchImmer- Datei.


    VaporiZed schrieb:

    Ich kenne keinen Weg, zur Laufzeit den Blockierer oder gar die Blockierstelle rauszufinden, aber das heißt nix.


    Da muss man den NT-API-Layer nutzen, also schon recht LowLevel. Mit NtQuerySystemInformation kann man sich alle File-Handles holen.
    codeproject.com/Articles/18975/Listing-Used-Files

    Wie man diese Handles dann schliesst/zerstört, müsste ich auch erstmal schauen. Aber das ist auch in dem verlinkten Projekt drin, wobei sich das was geändert haben könnte, ist ja schon recht alt das Projekt.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „DTF“ ()

    Da kannst auch einen Blick in die PowerToys von MS werfen. Ist ja OpenSource. Die haben da wohl auch soetwas drin wie Handles/Prozess auf geöffnete Dateien ermitteln und diese zu schließen. Doch vorsicht bei solchen Sachen. Die Doku sagt: WARNING: Closing handles can cause application or system instability.
    Mfg -Franky-

    Erstmal danke für die vielen Antworten :)

    -Franky- schrieb:

    Da kannst auch einen Blick in die PowerToys von MS werfen.

    Jou, hab ich gemacht. Nach ewigem Durchsteppen konnte ich dann rausfinden wo der Fehler lag und beheben. Ich konnte die betroffene Sub komplett zum Glück einfach so rausnehmen, weil die nur zum komfortablen Debuggen drin war :)