StreamWriter nicht die letzten Zeichen in eine Datei schreiben

Question

Wir haben ein Problem mit einem Server und es ist die Verwendung der StreamWriter-Klasse. Hat jemand etwas Ähnliches wie unten beschrieben erlebt? Wenn ja, mit welcher Lösung wurde das Problem behoben?

using(StreamWriter logWriter = File.CreateText(logFileName)) 
    { 
    for (int i = 0; i < 500; i++) 
     logWriter.WriteLine("Process completed successfully."); 
    } 

Wenn die Datei auszuschreiben die folgende Ausgabe erzeugt:

Process completed successfully. 
    ... (497 more lines) 
    Process completed successfully. 
    Process completed s 

logWriter.Flush Versuchte Zugabe() vor dem Schließen ohne Hilfe. Je mehr Textzeilen ich schreibe, desto mehr Datenverluste treten auf.

Answer 1

Kann dies nicht reproduzieren.

Unter normalen Bedingungen sollte dies nicht und wird nicht fehlschlagen.

• Ist das der tatsächliche Code, der fehlschlägt? Der Text "Prozess abgeschlossen" weist darauf hin, dass es sich um einen Auszug handelt.
• Irgendein Threading beteiligt?
• Netzwerklaufwerk oder lokal?
• usw.

Answer 2

Dies scheint sicher ein „Spülen“ Problem für mich zu sein, auch wenn Sie sagen, Sie einen Anruf() zu spülen hinzugefügt. Das Problem besteht möglicherweise darin, 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.

Versuchen Sie, den folgenden Code hinzu:

  logWriter.Flush(); 
      if (logWriter.BaseStream != null) 
       logWriter.BaseStream.Flush(); 

Answer 3

manchmal sogar nennen u flush(), es wird nur die Magie nicht. Becus Flush() bewirkt, dass der Stream die meisten Daten im Stream mit Ausnahme des letzten Blocks seines Puffers schreibt.

try 
{ 
// ... write method 
// i dont recommend use 'using' for unmanaged resource 
} 
finally 
{ 
stream.Flush(); 
stream.Close(); 
stream.Dispose(); 
} 

Answer 4

ich konfrontiert gleiche Problem

für mich gearbeitet Folge

using (StreamWriter tw = new StreamWriter(@"D:\Users\asbalach\Desktop\NaturalOrder\NatOrd.txt")) 
{ 
    tw.Write(abc.ToString());// + Environment.NewLine); 
} 

Answer 5

Hatte ein sehr ähnliches Problem selbst. Ich habe festgestellt, dass, wenn ich AutoFlush aktiviert habe, bevor irgendwelche Schreibvorgänge in den Stream und es wie erwartet funktioniert. logWriter.AutoFlush = true;

Answer 6

Dies haben den Trick für mich:

streamWriter.flush(); 

Answer 7

Mit Rahmen 4.6.1 und unter starken Belastung hat es immer noch dieses Problem. Ich bin mir 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 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 Cachedatei genau 1000 Frames hatte, hatten die geloggten Cash-Dateien alle unterschiedliche Größen.

hatte ich das Problem, wenn ich diese

//note, generateLogfileName is just a function to create a filename() 

using (FileStream fs = new FileStream(generateLogfileName(), FileMode.OpenOrCreate)) 
{ 
    using (StreamWriter sw = new StreamWriter(fs) 
    { 
    // do your stuff, but it will be unreliable 
    } 
} 

jedoch verwendet, wenn ich ihm einen Encoding-Typen vorgesehen, alle angemeldeten Dateien eine gleiche Größe erhalten, und das Problem war verschwunden.

using (FileStream fs = new FileStream(generateLogfileName(), FileMode.OpenOrCreate)) 
    { 
    using (StreamWriter sw = new StreamWriter(fs,Encoding.Unicode)) 
    { 
     // all data written correctly, no data lost. 
    } 
} 

Hinweis lesen Sie auch die Dateibreite der gleichen Codierungstyp!