El 30/07/2011 9:58, Bill Moo escribiķ:

On Fri, Jul 29, 2011 at 8:42 AM, <Viatcheslav.Sysoltsev@h-d-gmbh.de

<mailto:Viatcheslav.Sysoltsev@h-d-gmbh.de>> wrote:

This is a Boost.Interprocess bug that I don't think it can be easily solved. Once you lock a file in Windows, you can only write to it through the handle (internal to fileLock) used to lock it. That's why the handle inside "os" is blocked. I should note this in the documentation as file locking can only be used portably in Interprocess to control access to ANOTHER file (or resource) but not to limit access to the same file you've just locked. From MSDN:

http://msdn.microsoft.com/en-us/library/aa365203%28v=vs.85%29.aspx

"Locking a region of a file is used to acquire shared or exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region."

Best,