https://bugs.winehq.org/show_bug.cgi?id=37202
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |madewokherd@gmail.com
--- Comment #1 from Vincent Povirk madewokherd@gmail.com --- This is probably a WONTFIX. My guess is that the Linux version of LibreOffice locks the file differently from the Windows version. The Linux version probably range-locks the entire thing, while the Windows version uses CreateFile sharing semantics (not available on Linux).
You should see the same behavior as your Windows VM, if you run the Windows version of LibreOffice and Word in the same Wine prefix.
You may be able to see the broken behavior without involving Wine, if you run Linux LibreOffice and Word on real Windows, by putting the shared file on a network share (but it depends on how the file share protocol maps those locking operations).
In my testing, Windows does hang when opening a storage file, if byte 0x7fffff92 is locked. This is necessary to implement the rich locking semantics (see http://source.winehq.org/source/dlls/ole32/storage32.h#0504) of ole storage based on range locking.
LibreOffice could fix this by locking only bytes 0x7fffff93 through 0x7fffffe2. We're limited by the design decisions of MS, and I can't think of a way that we could implement the Windows API correctly while dealing with another program that range-locks the entire file. I'd be happy to discuss this further with LibreOffice devs.