[Mono-bugs] [Bug 46077][Nor] Changed - FileShare Enumeration is not implemented by Mono

[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 miguel@ximian.com.

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

--- shadow/46077	2003-07-10 06:20:49.000000000 -0400
+++ shadow/46077.tmp.12939	2004-05-12 21:44:36.000000000 -0400
@@ -1,22 +1,21 @@
 Bug#: 46077
-Product: Mono/Runtime
+Product: Mono: Runtime
 Version: unspecified
 OS: Red Hat 9.0
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: misc
-AssignedTo: mono-bugs@ximian.com                            
+AssignedTo: dick@ximian.com                            
 ReportedBy: richard.torkar@htu.se               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
 Summary: FileShare Enumeration is not implemented by Mono
 
 The following code snippet (from msdn) shows that mono does not yet
 implement  FileShare.None correctly. (The library seems to have the enum at
 least :)
 
@@ -70,6 +69,48 @@
 }
 
 /* END EXAMPLE */
 
 At the moment, latest mono cvs (2003-07-09) gives this:
 The file was not locked, and was opened by a second process.
+
+------- Additional Comments From richard.torkar@htu.se  2003-09-24 08:08 -------
+This is still unimplemeted in mono cvs from september.
+
+------- Additional Comments From miguel@ximian.com  2003-10-17 14:22 -------
+I am not sure if we want to implement this, first because not every
+unix has mandatory locking, and when it does, it becomes a pain in the
+neck to fix it.
+
+In particular, I remember rpm leaving the database locked and
+requiring a reboot.
+
+Dick, can you comment on this?
+
+------- Additional Comments From dick@ximian.com  2003-10-20 10:56 -------
+I guess we can implement it on systems that support it, and just fail
+to lock on others.  However...
+
+The default FileShare value for the other File.Open() methods is
+FileShare.None, which would mean that just about every file opened
+would be mandatorily locked.  That would suck.  I don't know how large
+the kernel lock tables are these days, but it can't be a good idea to
+lock every single open file.
+
+And this last paragraph from linux/Documentation/mandatory.txt:
+
+6. Warning!
+-----------
+
+Not even root can override a mandatory lock, so runaway processes can
+wreak havoc if they lock crucial files. The way around it is to change
+the file permissions (remove the setgid bit) before trying to read or
+write to it. Of course, that might be a bit tricky if the system is
+hung :-(
+
+[The file permissions refers to a ghastly hack by the SysV designers:
+a file with the setgid bit but not the group-exec bit in its file mode
+is a candidate for mandatory locking.]
+
+
+------- Additional Comments From miguel@ximian.com  2004-05-12 21:44 -------
+Assigning to Dick, related to Lock/Unlock support.