none
File.IO.WriteTextAsync schreibt nicht in die korrekte Datei RRS feed

  • Frage

  • Guten Tag

    In einem BackgroundTask erstelle ich eine leere Textdatei, falls diese nicht vorhanden ist (Cache.txt). Im späteren Codeverlauf beschreibe ich diese Datei mit einem Inhalt auf folgende Weise

    await FileIO.WriteTextAsync(cacheFile, content);

    Dies funktioniert beim manuellen ausführen des BackgroundTask auch einwandfrei. Lasse ich den BackgroundTask allerdings nun vom System (alle 30 Minuten) ausführen, wird der Inhalt nicht in die Cache.txt geschrieben, sondern es wird mir eine weitere Datei Namens "Cache.txt.~tmp" erstellt, worin dann der neu geschriebene Inhalt erzeugt wird. Die eigentliche "Cache.txt" Datei wird daher nie wieder angefasst, es wird immer nur die "Cache.txt.~tmp" beschrieben bzw. aktualisiert. Beim debuggen erhalte ich nirgendwo eine Exception oder sonst etwas, ich kann den Fehler daher nicht nachvollziehen.

    Kann mir jemand weiterhelfen?

    Mit freundlichen Grüssen

    Donnerstag, 28. April 2016 07:21

Antworten

  • Hallo Andy,

    ich weiß hier auch nicht wie die StorageFile-Objekte genau arbeiten. Ich habe allerdings schon mehrfach mitbekommen dass diese nicht einfach nur ein Wrapper um die Dateipfade sind. Da steckt noch ein bisschen mehr dahinter. Und das wird hier vermutlich das Problem sein. Ich habe ein paar Theorien:

    1. Der Stream auf die Datei wird in der eigentlichen Anwendung (im Backgroundtask) nicht ordentlich geschlossen. Und der Backgroundtask der theoretisch in der Lage wäre parallel die selbe Datei zu beschrieben (also es zumindest versucht) umgeht das hier indem er eine 2. Datei anlegt.
      Statt dem Stream-Problem liegt es vielleicht daran, dass du das StorageFile-Objekt einfach an den BackgroundTask übergibst? Also eine Art Kopie angelegt wird.
    2. Die Datei wird zwar unter einem anderen Namen gespeichert, aber wird auch inklusive Inhalt gefunden wenn du den eigentlichen Dateinamen aufrufst. Vielleicht liegt es an dem Ordner in dem du versuchst du speichern? Welcher ist das? Versuche es mal auf dem Desktop o.ä.

    Interessant wäre noch ob das Problem reproduzierbar ist. Wenn ja, kannst du das Projekt mit uns teilen? Das würde uns die Arbeit ersparen es nochmal komplett neu zu schreiben.


    Tom Lambert - .NET (C#) MVP
    Wozu Antworten markieren und für Beiträge abstimmen? Klicke hier.
    Nützliche Links: .NET Quellcode | C# ↔ VB.NET Konverter | Account bestätigen (Verify Your Account)
    Ich: Webseite | Code Beispiele | Facebook | Twitter | Snippets

    • Als Antwort markiert andy-dev Sonntag, 1. Mai 2016 04:44
    Donnerstag, 28. April 2016 21:49

Alle Antworten

  • Hallo Andy,

    wirklich weiter helfen kann ich dir bei diesem Problem leider auch nicht. Ein paar Ideen habe ich aber was man mal überprüfen sollte:

    1. Wie holst du dir das StorageFile-Objekt? Vielleicht liegt dort der Fehler?
    2. Wenn du dir die Path-Eigenschaft von cacheFile ausgeben lässt (Debug.WriteLine o.ä.), was bekommst du da? Den richtigen oder den falschen Dateinamen?

    Tom Lambert - .NET (C#) MVP
    Wozu Antworten markieren und für Beiträge abstimmen? Klicke hier.
    Nützliche Links: .NET Quellcode | C# ↔ VB.NET Konverter | Account bestätigen (Verify Your Account)
    Ich: Webseite | Code Beispiele | Facebook | Twitter | Snippets

    Donnerstag, 28. April 2016 14:14
  • Hallo Tom

    Danke für deine Antwort. Ich habe mir testweise eine Toastbenachrichtigung eingerichtet, welche mir die Path-Eigenschaft des StorageFile-Objekts ausgibt. Merkwürdigerweise wird mir da die korrekte Datei (Cache.txt) ausgegeben, jedoch ist diese, wenn ich im Installationspfad (c:\users\benutzer\appdata\local\packages\appid\localstate) nachschaue, zwar vorhanden, allerdings leer und eine weitere Datei Namens "Cache.txt.~tmp" liegt mit dem selben Änderungsdatum dort drin. Der Inhalt, welchen ich mit "WriteTextAsync" schreibe, befindet sich jedoch nur in dieser .~tmp Datei.

    Ich kann es mir einfach nicht erklären.

    Mit freundlichen Grüssen

    Donnerstag, 28. April 2016 17:19
  • Hallo Andy,

    ich weiß hier auch nicht wie die StorageFile-Objekte genau arbeiten. Ich habe allerdings schon mehrfach mitbekommen dass diese nicht einfach nur ein Wrapper um die Dateipfade sind. Da steckt noch ein bisschen mehr dahinter. Und das wird hier vermutlich das Problem sein. Ich habe ein paar Theorien:

    1. Der Stream auf die Datei wird in der eigentlichen Anwendung (im Backgroundtask) nicht ordentlich geschlossen. Und der Backgroundtask der theoretisch in der Lage wäre parallel die selbe Datei zu beschrieben (also es zumindest versucht) umgeht das hier indem er eine 2. Datei anlegt.
      Statt dem Stream-Problem liegt es vielleicht daran, dass du das StorageFile-Objekt einfach an den BackgroundTask übergibst? Also eine Art Kopie angelegt wird.
    2. Die Datei wird zwar unter einem anderen Namen gespeichert, aber wird auch inklusive Inhalt gefunden wenn du den eigentlichen Dateinamen aufrufst. Vielleicht liegt es an dem Ordner in dem du versuchst du speichern? Welcher ist das? Versuche es mal auf dem Desktop o.ä.

    Interessant wäre noch ob das Problem reproduzierbar ist. Wenn ja, kannst du das Projekt mit uns teilen? Das würde uns die Arbeit ersparen es nochmal komplett neu zu schreiben.


    Tom Lambert - .NET (C#) MVP
    Wozu Antworten markieren und für Beiträge abstimmen? Klicke hier.
    Nützliche Links: .NET Quellcode | C# ↔ VB.NET Konverter | Account bestätigen (Verify Your Account)
    Ich: Webseite | Code Beispiele | Facebook | Twitter | Snippets

    • Als Antwort markiert andy-dev Sonntag, 1. Mai 2016 04:44
    Donnerstag, 28. April 2016 21:49
  • Vielen Dank für deine Antwort Tom. Ist mir nun zwar etwas peinlich, allerdings habe ich den (selbstverschuldeten) Fehler gefunden. Da in meinem BackgroundTask das beschreiben des TextFiles asynchron abgearbeitet werden soll, habe ich doch glatt vergessen, den Deferral zu setzen

    //...
    
    BackgroundTaskDeferral _deferral = taskInstance.GetDeferral();
    
    // BackgroundTask Code ...
    
    _deferral.Complete();
    
    // ...

    Dabei habe ich schon mehrmals BackgroundTasks genutzt. Naja jedenfalls ist das Problem damit behoben. Allerdings hätte ich niemals mit einem solch merkwürdigen verhalten gerechnet.

    Trotzdem markiere ich deine Antwort als Lösung, da du mir versucht hast zu helfen.

    Mit freundlichen Grüssen


    • Bearbeitet andy-dev Sonntag, 1. Mai 2016 04:44
    Sonntag, 1. Mai 2016 04:43