2017-09-13 3 views
-2

Ich habe den folgenden Code, um eine Datei zu schreiben. Das Problem ist, dass wenn ich die gleiche Datei überschreiben möchte, sie "gesperrt" ist. Die Datei wird von einem anderen Prozess geöffnet.Filestream nicht Datei für andere Prozesse frei

using (FileStream fs = new FileStream("C:\\New\\" + fileName, FileMode.Create, FileAccess.ReadWrite)) 
using (StreamWriter str = new StreamWriter(fs)) 
{ 
    str.Write(jsonFile); 
    str.Dispose(); 
    str.Close(); 
} 

Ich sende eine JSON-Zeichenfolge an eine API, die dann die Datei generiert. Also ich denke, es könnte ein Problem in IIS sein.

EDIT: Durch Forschung Ich habe immer noch den folgenden Code versucht, aber das führt zu dem gleichen Ergebnis

using (FileStream fs = new FileStream("C:\\New\\" + fileName, FileMode.Create, FileAccess.ReadWrite)) 
{ 
    StreamWriter sw = new StreamWriter(fs); 
    sw.Write(jsonFile); 
    fs.Flush(); 
    fs.Close(); 
} 

EDIT 2: Nach dem Lesen der Kommentare, es hat wahrscheinlich nichts mit dem Filestream zu tun selbst. Hier finden Sie weitere Informationen zu meiner Anwendung: Ich habe eine WPF-Anwendung, die einen Post über ein ButtonClick an meine API sendet. Dies löste sich wie folgt:

private async void btnSend_Click(object sender, RoutedEventArgs e) 
    { 
     await Seal(); 
    } 

Die Seal-Methode sagt der folgende:

private async System.Threading.Tasks.Task Seal() 
    { 
     var result = await RequestManager.DoPost<bool>("FOO", foo); 
    } 

Die RequestManager sagt der folgende:

public static async Task<R> DoPost<R>(String route, Object payload, String contenttype) 
    { 
     var serializer = new JavaScriptSerializer(); 

     route = route.StartsWith("/") ? route : "/" + route; 

     var content = new StringContent(serializer.Serialize(payload), Encoding.UTF8, contenttype); 

     var response = await client.PostAsync(RequestManager.API_URL + route, content); 

     if (response.StatusCode == HttpStatusCode.OK) 
     { 
      var result = await response.Content.ReadAsStringAsync(); 
      return (R)serializer.Deserialize(result, typeof(R)); 
     } 
     else 
     { 
      throw new ResponseException(response.StatusCode, response.Content.ReadAsStringAsync().Result); 
     } 
    } 

Ich weiß wirklich nicht, wo mein Fehler ist, oder wo die Anfrage geschlossen werden muss.

+5

Die 'Dispose' und' Close' Anrufe sind redundant mit einer 'using'-Anweisung –

+1

Sie benötigen weitere Informationen, das von Ihnen oder einem anderen Prozess gesperrt werden werden könnte. Bitte geben Sie die Schritte zur Neuerstellung an. Zum Beispiel, was genau nennt das? Ist dies eine Multi-User-, Multi-Threading- oder Web-Umgebung? Offensichtlich kann eine Datei nicht gleichzeitig mit mehreren Prozessen beschrieben werden. – Liam

+1

https://xkcd.com/1888/ –

Antwort

-1

Dieser Fehler kann auftreten, wenn mehrere Threads versuchen, in derselben Datei zu schreiben. Ihr Code funktioniert oben mit einer kleinen Modifikation

private static object lk = new object(); 
    lock (lk) 
     { 
    using (FileStream fs = new FileStream("C:\\New\\" +fileName,FileMode.Create, FileAccess.ReadWrite)) 
using (StreamWriter str = new StreamWriter(fs)) 
{ 
str.Write(jsonFile); 
str.Dispose(); 
str.Close(); 
} 
    } 
+0

Es hat keinen Sinn, dort zwei Anweisungen zu verwenden. Das Umbrechen aller in der ersten using-Anweisung funktioniert einwandfrei. – codein

+0

Wenn es zuvor ein Problem mit dem gemeinsamen Zugriff gegeben hat, gibt es jetzt 2^N - diese Sperre blockiert * alle * Dateischreibvorgänge, unabhängig davon, ob sie versuchen, in dieselbe Datei zu schreiben oder nicht. Wer hat gesagt, dass 'FileStream' oder' using' trotzdem kaputt sind? Sie werden millionenfach pro Tag von Tausenden von Websites verwendet, ohne dass zusätzliche Sperren erforderlich sind. Wenn Probleme auftreten, ist es der * Code *, der die Störung verursacht –

+0

Ich habe versucht, Ihr Problem mit all Ihren Code Samples zu reproduzieren, aber alle bestanden, außer wenn ich versuchte, in die Datei parallel zu schreiben, die ich löste, indem Sie die Sperre hinzufügten. Wenn Sie sich auf dem Entwicklungscomputer befinden, können Sie versuchen, die Datei manuell zu löschen und erneut zu testen. – codein

Verwandte Themen