I figured this one out on my own (surprise), and yes, I was wrong.

See the bug if you're really interested, but suffice to say that I should've listened to Dick.

/me slinks back to the car wash

Bill


On 4/27/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
Hello group,

I've been trying to help work out bug number 74732:

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

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.  Clearly, Dick is very busy right now.

To avoid that, I've decided to simply subject myself to the ridicule of the group if I'm wrong. :-)

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:

A. Another running mono process has the file open
B. A mono process had the file open and crashed without clearing the handle

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.  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.   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.

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.  How?  

Simply add a pid member to the wapi filehandle.  When a file is opened in a non-shared mode, set the pid.  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.  If it's not, then it's ok to clear the handle and reopen the file.

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  constructor, I believe this will work.  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.  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.

Does this sound correct?  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  process, including threads?  If so, then please confirm.  If not, then let the ridiculing begin.  :)

Bill


Reply via email to