[Mono-bugs] [Bug 74732][Blo] Changed - Sharing/Access violation after exiting a running mono app with an open StreamWriter (SVN checkouts)

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by flashdict@gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=74732

--- shadow/74732	2005-04-29 15:57:17.000000000 -0400
+++ shadow/74732.tmp.15397	2005-04-29 19:44:52.000000000 -0400
@@ -203,6 +203,77 @@
 
 
 
 ------- Additional Comments From dick@ximian.com  2005-04-29 15:57 -------
 Try now.  I need to test the combinations of share more thoroughly
 still so I'm not marking it as fixed just yet...
+
+------- Additional Comments From flashdict@gmail.com  2005-04-29 19:44 -------
+Your latest change is probably as good as it's going to get without
+implementing a privileged (kmem) solution for OS's with non-compliant
+or nonexistent /proc.  
+
+As I found out though, it's not good enough to completely replace your
+current technique.  Here's an example:
+
+Open three windows under OSX.  Then, in the first two windows, run the
+following code, which opens a shared file for write/append.  Each
+process will append a "..." to the logfile, and wait for you to type
+"quit".
+
+using System;
+using System.IO;
+class ViolationDemo
+  {
+    [STAThread]
+    static void Main(string[] args)
+    {
+      StreamWriter writer = null;
+      FileStream s = new FileStream("TestApp.log", FileMode.Append, 
+                           FileAccess.Write, FileShare.Write);
+      string command = string.Empty;
+      writer = new StreamWriter(s,System.Text.Encoding.UTF8,4096);
+      writer.AutoFlush = true;
+      writer.WriteLine("...");
+      while(command != "quit")
+        command = Console.ReadLine().ToLower();
+    }
+  }
+
+Now, with both processes still running, run the following code in the
+third window.  This code tries to open the file unshared with
+write/truncate.  It will fail with a sharing exception, but only so
+long as the _first_ process/window you started  is not terminated.  If
+you terminate the first window, either with "quit" or ^C, then this
+will succeed, truncating the file.  
+
+using System;
+using System.IO;
+class ViolationDemo
+  {
+    [STAThread]
+    static void Main(string[] args)
+    {
+      StreamWriter writer = null;
+      string command = string.Empty;
+      writer = new StreamWriter("TestApp.log", false,
+System.Text.Encoding.UTF8, 4096);
+      writer.AutoFlush = true;
+      writer.WriteLine("...");
+      while(command != "quit")
+        command = Console.ReadLine().ToLower();
+    }
+  }
+
+My second patch (see above) tries to work around the problem, by
+resetting the pid when a new process opens the file, but that
+introduces another problem, in that the _second_ window now can be
+terminated, allowing the file to be truncated.  Feh.
+
+One  fix that I imagine (I dare not try it) for this is to somehow
+reset the new WapiFileShare pid on thread/process termination _and_
+creation, but that still doesn't handle crashes or SIGINT.  
+
+I now believe that your original mail reply to my "idea" here was
+correct, Dick.  The only way to do this in a foolproof way is to
+manage a dynamic array of pids in shared memory.
+