[Mono-dev] Mutex Bug

[Vladimir Dimitrov]

I guess I will be having the same problem as you. So why not just use a 
file in the temp folder with a unique name somehow connected with the 
locked resource (like <company_name>-<product_name>.lck) and just try to 
open it with no sharing? This together with poling should be enough. Why 
do you need all that cryptography?

- Vlad

On 3.7.2014 г. 06:32 ч., Edward Ned Harvey (mono) wrote:
>> From: Brandon Perry [mailto:bperry.volatile at gmail.com]
>>
>> Do you *have* to write to the same file?
> Yes.  Here is the situation:
> https://tinhatrandom.org
> An open source, MIT licensed class library aimed at improving crypto random available to the application developer...
>
> One of the things we need to do is this:  Assuming we have collected a lot of good entropy from various entropy sources, save a good strong random seed file on disk.  Later, any number of applications may be launched, potentially at the same time, which need to read & write the file, mutually exclusively.
>
> The reason it needs to be one file, is because that's the whole point - If the user has already entered random keyboard input, random mouse input, and we gathered entropy from the internet, and RNGCryptoServiceProvider, and other sources, then every application launch shouldn't need to repeat that.  First one does it; everyone later benefits from it.
>
> Right now, I believe, if I use FileMode.Open,  FileAccess.ReadWrite, and FileShare.None, that should work cross-platform to ensure only a single process may access the file at a time.  The process/thread that has the file lock can read the seed, write a new seed, and flush and close.  It will work reliably, I believe, for the first process that gets there, and to prevent any subsequent processes from accessing the same seed file before it is reseeded.  Any subsequent processes that fail to open the file (because another process already has it open) I think, will simply have to Sleep(1) and retry opening the file.  It's a little ghetto, but it should work AFAIK.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list