[Mono-bugs] [Bug 46077][Nor] Changed - FileShare Enumeration is not implemented by Mono
Wed, 12 May 2004 21:44:36 -0400 (EDT)
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 email@example.com.
--- 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 @@
+Product: Mono: Runtime
OS: Red Hat 9.0
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
@@ -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 firstname.lastname@example.org 2003-09-24 08:08 -------
+This is still unimplemeted in mono cvs from september.
+------- Additional Comments From email@example.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 firstname.lastname@example.org 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:
+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
+[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 email@example.com 2004-05-12 21:44 -------
+Assigning to Dick, related to Lock/Unlock support.