Jun 21, 2022

3168

Filestream wird nicht freigegeben

Hallo,

ich hab da ein kleines Problem bei beschreiben einer Datei

Und zwar nutze ich folgenden Code. Das ganze funktioniert auch bei einmaliger Ausführung.

using (var stream = File.Open(Properties.Settings.Default.Dateipfad + @"\Ergebniss.csv", FileMode.OpenOrCreate))  
                {
                    StreamWriter sr = new StreamWriter(stream);
                    opline = fcount[1] + ";" + string.Join(";", Wert);  
                    sr.WriteLine(opline);
                    sr.Dispose();
                }

Nur leider wenn ich die Funktion während der Programmlaufzeit ein zweites mal ausführe bekomme ich eine System.IO.IOException das die Datei schon in Verwendung.
Sprich er gibt sie mir nach dem ersten schreiben nicht mehr frei.

Hat da von euch jemand einen kleinen Tipp für mich?
Schon mal vielen Dank

Please also mark the comments that contributed to the solution of the article

Content-Key: 3132379263

Url: https://administrator.de/contentid/3132379263

Printed on: April 25, 2024 at 02:04 o'clock

15 Comments

Latest comment

https://stackoverflow.com/questions/13698380/filestream-locking-a-file-f ...

Generell wie es dort steht eher schließen, mit using arbeiten?

Ok, dein Beispiel ist hart an dem Beitrag. War irgendwie verpeilt. Komme grad nicht drauf, wie ich es damals gemacht hab aus SQL DB Word Dokumente extrahier u.ä. Finde gerade meine Quellcode nicht wieder.

Using hätte ich zwar schon drinnen beim File.open aber auch bei

using (StreamWriter sr = new StreamWriter(Properties.Settings.Default.Dateipfad + @"\Ergebniss.csv", true))  
                {
                    opline = fcount[1] + ";" + string.Join(";", Wert);  
                    sr.WriteLine(opline);
                }

ist das Ergebnis leider das selbe.

Code Beispiel

Musste es nur schnell unkenntlich machen.

Bissel viel. Der SQL Reader liest Blobs und extrahier alle Word Dokumente.

Am Ende werden die temp Dateien von C: gelöscht. Ist also auf jedenfall dort "frei".

Überleg gerade zu deinen Beispiel. Kaskadieren? Normal verwende ich hier auch

FileStream fs = new FileStream(@"c:\sig\" + newFilename, FileMode.Create);  
fs.Write(Data, 0, Data.Length);
fs.Close();

Bin etwas eingerostet. Hab das vor 3 J. mal gebaut. Siehst du was interessantes für dich?

"c:\sig" ja ja es musste schnell gehen. Aber es lief....

PS: Ist etwas viel wie gesagt.
- SQL Query ob in den letzten 2 Std. was an Daten auflief - hier gekürzt dargestellt
- Binary in ZIP Form
-- Werden Entpackt und je nach Dok-Namen (Column auf SQL Server) als Word etc. gesepeichert
- Alle werden als Attachment aufgenommen
- Via Mail gesendet.
- Am Ende werden alle Dateien wieder gelöscht

Sowohl Versand als auch Löschen geht. Hier sollte kein Lock mehr sein.

musst du den streamwriter nicht einfach schließen mit sr.close()?

Zitat von @Reinartz:

musst du den streamwriter nicht einfach schließen mit sr.close()?

Mir ist auch so. In meinen Beispiel schließe ich sofort nach dem Write.

Ist wie gesagt alles "frei".

Ist auf jeden Fall interessant.
Die Datei selbst ist sogar "frei". Ich kann sie Problemlos löschen.
Aber selbst dann wenn sie für den zweiten Aufruf gelöscht ist sagt er mir immer noch das sie in Verwendung ist.

bei using sollte er eigentlich alles selbst verwerfen aber auch sr.close() bringt mir den Fehler und sr.dispose() legt ja dann noch eins drauf und sollte alles verwerfen.

Blockiert das Studio? Sehr komisch. Bei mir müsste der "close" gereicht haben.

Bei mir kreist ja nur der Writer und schreibt die Dateien aus der DB weg. Dann ZIP Krams und am Ende wird gelöscht. Siehst du ja.

Wegen Klammern hab ich extra den ganzen Code gepostet. Nur SQL eingekürzt und unwichtige Dinge. Seltsam.

@wiesi200 bei mir ist es ja kaskadiert. SQL Klasse.

Stackoverlflow hat er ja sowas geschrieben:

private static object lockObject = new object();

lock (lockObject) 
{
    using(var sw = new StreamWriter(fs))
    {
       sw.Write(str + text);
    }
}

Brauchen wir ne Klasse dafür? Bin arg eingerostet.

Bei dir halt "writeObject" oder sowas meinetwegen. Sonst sehe ich auch gerade den Wald vor lauter Bäumen nicht.

Ich mach so spaß auch vielleicht 1x im Jahr.

Das allerlustigest, ich hab das jetzt mal in ein try gepackt.
Trotz der Fehlermeldung schreibt der schön brav wie er eigentlich soll.

Auch wenn mich jetzt jeder anständige Programmierer schimpfen wird und das zurecht.
Ich verwerfe jetzt mal die exception und gut ist. Und der der schimpfen mag kann mir die Lösung nennen.

Finde gerade auch nichts weiter.

C# Programmierer scheinen nicht viel auf die feste Platte zu schreiben

Bei mir ist auch grad Ebbe. Das neue object, was er da einsetzt - da könnte noch was dran sein.

Hab leider die DB nicht mehr für meinen Code. Ich bin mir aber ziemlich sicher dass es keine Exception geschmissen hat.

http://rizwanansari.net/write-text-file-without-read-lock-in-csharp/

@wiesi200
Ansatz ohne exklusive Sperre. Ggf. ist das noch was?

https://dotnet-snippets.de/snippet/file-readline-without-lock/15197

Oder fehlt noch ein using... Finde gerade immer mehr.

Hurra jetzt passt es.
Hier mal der Spaß ungekürzt

            try 
                {
                using (var stream = File.Open(Properties.Settings.Default.Dateipfad + @"\" + textBox1.Text + @"\" + textBox1.Text + "_Ergebniss.csv", FileMode.OpenOrCreate, FileAccess.Write, FileShare.ReadWrite))  
                {
                    StreamWriter sr = new StreamWriter(stream);
                    
                    if (fexists != true)
                    {
                        opline = "Nr.;Messung_1;Messung_2;Messung_3;Messung_4;Messung_5;Messung_6;Messung_7;Messung_8;Messung_9;Messung_10;Durchschnitt";  
                        sr.WriteLine(opline);
                    }
                    opline = textBox1.Text + "-" + fcount[1] + ";" + string.Join(";", Wert) + ";" + avg.ToString();  
                    sr.WriteLine(opline);
                    sr.Close();
                }
                
                
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.ToString());
            }

Vielen Dank für die Hilfe

Na geht doch!

War vorhin eh am wühlen und hab das ncoh bei mir gefunden. Durch try-catch eig. überflüssig.

Damit kannst du testen, ob ein lock vorliegt. Der Vollständigkeit halber.

$fileName = "c:\temp\test-file.txt"  
$file = New-Object -TypeName System.IO.FileInfo -ArgumentList $fileName
$ErrorActionPreference = "SilentlyContinue"  
[System.IO.FileStream] $fs = $file.OpenWrite(); 
if (!$?) {
    $msg = "Can't open for write!"  
}
else {
    $fs.Dispose()
    $msg = "Accessible for write!"  
}
$msg

Kurz noch abschließend zur Info.
Das Problem ist dann später wieder aufgetaucht mit noch 1-2 anderen am Rand.

Ich hab dann mal mit einem Tread.Sleep das Programm kurz pausiert. Anscheinend war die Verarbeitung einfach zu schnell.

Hallo

ja Sleep nehm ich meist auch. Irgendwie immer Kacke.

Alternativ könntest du nur sowas wie eine Antwort höher einbauen. Loopen und prüfen ob Datei beschreibbar ist. Wenn ja, Dispose und weiter gehts.

Frage ist, ob sich das lohnt. Loop im ms Bereih. Wenn man da 1, 2 Sek. einbaut, kann man es auch gleich lassen und generell pausieren. Filesystem ist immer träge.

German solved Question Visual Studio Development

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments