[Mono-devel-list] Re: Regarding file sharing in .NET and Mono

Bill Middleton flashdict at gmail.com
Thu Apr 28 16:23:11 EDT 2005

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


On 4/27/05, Bill Middleton <flashdict at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050428/61c68d56/attachment.html 

More information about the Mono-devel-list mailing list