I figured this one out on my own (surprise), and yes, I was wrong.<br>
See the bug if you're really interested, but suffice to say that I should've listened to Dick.<br>
/me slinks back to the car wash<br>
<br><br><div><span class="gmail_quote">On 4/27/05, <b class="gmail_sendername">Bill Middleton</b> &lt;<a href="mailto:flashdict@gmail.com">flashdict@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello group,<br>
I've been trying to help work out bug number 74732:<br>
<a href="http://bugzilla.ximian.com/show_bug.cgi?id=74732" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bugzilla.ximian.com/show_bug.cgi?id=74732</a><br>
I suspect that, in spite of his immense capacity to deliver excellent
works, (or possibly because of that) I may be starting to irritate the
developer in charge of fixing the problem with my suggestions.&nbsp;
Clearly, Dick is very busy right now.<br>
To avoid that, I've decided to simply subject myself to the ridicule of the group if I'm wrong. :-)<br>
Now, for those who are familiar with the io-layer, you'll know that it
performs a check when opening a file, to see if the wapi filehandle
exists for the file. If a wapi filehandle exists, then one of the
following is true:<br>
A. Another running mono process has the file open <br>
B. A mono process had the file open and crashed without clearing the handle<br>
In both cases, the io-layer peforms another check in the (supported)
/proc filesystem, to see if any other mono process truly has the file
open, and if not, then the handle is cleared, and the file is allowed
to be opened.&nbsp; Unfortunately, not all operating systems which run
Mono have a procfs(5) which supports that secondary check, which relies
on checking each and every file opened by every PID running on the
system to see if it matches the one we currently want to open. &nbsp;
This leaves OSX and FreeBSD, along with any other system which doesn't
have, or doesn't enable /proc with a sharing exception, even if the the
original opening process is long dead.<br>
After groping about for awhile with debug modes in the io-layer, and
reading some in MSDN, it has occured to me that the check to see
whether a given file is actually open by a running process could be
greatly simplified, and made to fully support any OS.&nbsp;
How?&nbsp;&nbsp; <br>
Simply add a pid member to the wapi filehandle.&nbsp; When a file is
opened in a non-shared mode, set the pid.&nbsp; If another process
comes along and wants to open the file, and the file isn't shared, it
simply needs to check if the pid which is attached to the wapi
filehandle is still running.&nbsp; If it's not, then it's ok to clear
the handle and reopen the file.<br>
Because .NET (and thus Mono) cannot allow a file to be opened by more
than a single process unless one of the FileShare enum values
(FileShare.Read, FileShare.Write, etc) was passed in as an argument to
the FileStream&nbsp; constructor, I believe this will work.&nbsp; If
the file was opened in a shared mode, then it can always be reopened,
even if the original process crashed and left the handle
uncleared.&nbsp; If it was opened in a non-shared mode, then it can
only be opened again if the PID which opened the file originally is
dead, and a simple check in the toplevel /proc directory (or via other
non-privileged means) can tell us if a given PID is alive.<br>
Does this sound correct?&nbsp; Is it not the case that .NET absolutely
requires FileShare.Write to be set, before a file can be opened for
writing by more than one .NET&nbsp; process, including threads?&nbsp;
If so, then please confirm.&nbsp; If not, then let the ridiculing
begin.&nbsp; :)<br><span class="sg">