Wir haben ein Problem mit einem Server und verwenden die StreamWriter-Klasse. Hat jemand etwas Ähnliches wie unten beschrieben erlebt? Wenn ja, mit welcher Lösung konnte das Problem behoben werden?
%Vor%Beim Schreiben der Datei wird die folgende Ausgabe generiert:
%Vor%Es wurde versucht, logWriter.Flush () vor dem Schließen ohne Hilfe hinzuzufügen. Je mehr Textzeilen ich schreibe, desto mehr Datenverluste treten auf.
Kann das nicht reproduzieren.
Unter normalen Bedingungen sollte dies nicht und wird nicht fehlschlagen.
manchmal sogar rufen Sie flush (), es wird einfach nicht die Magie tun. Becus Flush () bewirkt, dass der Stream die meisten Daten im Stream außer dem letzten Block seines Puffers schreibt.
%Vor%Das scheint mir ein Problem zu sein, obwohl Sie sagen, dass Sie Flush () hinzugefügt haben. Das Problem kann sein, dass Ihr StreamWriter nur ein Wrapper für ein zugrunde liegendes FileStream-Objekt ist.
Normalerweise verwende ich die File.CreateText-Methode nicht, um einen Stream zum Schreiben in eine Datei zu erstellen. Normalerweise erstelle ich meinen eigenen FileStream und wickle ihn dann bei Bedarf mit einem StreamWriter um. Ungeachtet dessen bin ich in Situationen geraten, in denen ich Flush sowohl beim StreamWriter als auch beim FileStream aufrufen musste, also stelle ich mir vor, dass dies dein Problem ist.
Fügen Sie den folgenden Code hinzu:
%Vor%Unter Verwendung von Framework 4.6.1 und unter starker Belastung hat es immer noch dieses Problem. Ich bin nicht sicher, warum es das tut, obwohl ich einen Weg gefunden habe, es sehr anders zu lösen (was mein Gefühl verstärkt, dass es tatsächlich ein .net Bug ist).
In meinem Fall habe ich versucht, riesige gezackte Arrays auf die Festplatte zu schreiben (Video-Caching). Da das gezackte Array ziemlich groß ist, musste es viele wiederholte Schreibvorgänge ausführen, um eine große Menge von Videoframes zu speichern, und obwohl sie unkomprimiert waren und jede Cache-Datei genau 1000 Frames hatte, hatten die geloggten Cash-Dateien alle unterschiedliche Größen.
>Ich hatte das Problem, als ich das verwendete
%Vor%Wenn ich jedoch einen Encoding-Typ angegeben habe, haben alle geloggten Dateien die gleiche Größe und das Problem ist weg.
%Vor%Beachten Sie auch, dass die Dateibreite den gleichen Kodierungstyp hat!