https://bugs.winehq.org/show_bug.cgi?id=37202
Bug ID: 37202 Summary: MSWord hangs on opening a document opened in other program Product: Wine Version: 1.7.24 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs@winehq.org Reporter: b7.10110111@gmail.com
Created attachment 49455 --> https://bugs.winehq.org/attachment.cgi?id=49455 Backtrace from winedbg. Process stopped by Ctrl+C after hanging.
How to reproduce:
1. Have a .doc file 2. Open it in LibreOffice 3. Try opening it from MS Word 4. See Word hang 5. Close LibreOffice 6. See file finally opened in MS Word, it's no longer hung
As I've tested similar scenario in a virtual machine, there Word gives a dialog saying that the file is locked for reading by another process.
It's a regression: 65887802c502c4eeeb3fc905990e3e2f4548a482 is the first bad commit commit 65887802c502c4eeeb3fc905990e3e2f4548a482 Author: Vincent Povirk vincent@codeweavers.com Date: Fri Apr 18 16:37:56 2014 -0500
ole32: Initial storage file locking implementation.
:040000 040000 b86f27a6f6561d9f35fd01166388e2e7a0380c28 68646bad80d38b40a014cb1cbd57b62aa19abad2 M dlls
The hang occurs in NtDelayExecution called by NtLockFile (see attached backtrace).
https://bugs.winehq.org/show_bug.cgi?id=37202
Ruslan Kabatsayev b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |65887802c502c4eeeb3fc905990 | |e3e2f4548a482
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.
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #2 from Ruslan Kabatsayev b7.10110111@gmail.com --- Indeed, it works with Windows version of LibreOffice as expected. But if I run LibreOffice and Word from different wine prefixes, the locks seem to not work at all, i.e. file is freely opened by Word, as before the commit. Is it intended?
Also, should I file a bug report to LibreOffice? (I guess it'd count as "enhancement" there, not a "bug", right?)
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #3 from Vincent Povirk madewokherd@gmail.com --- The issue with separate prefixes is unfortunately a limitation of Wine: CreateFile sharing semantics don't exist on Linux, and so we have to implement them in wineserver, meaning they only work within the same prefix. Multiple instances of Word in separate prefixes (including over network shares with Windows, if range locking works on the network filesystem) should work correctly, because of the change that caused this bug.
Please file a LibreOffice bug and CC me. It's debatable whether they're really doing anything wrong (though I would argue that they have to be prepared to interact with Windows programs over a network share, and what they're currently doing could break that), so enhancement seems appropriate, but I don't think we can fix it on our end.
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #4 from Ruslan Kabatsayev b7.10110111@gmail.com --- Reported: https://bugs.freedesktop.org/show_bug.cgi?id=83282
I couldn't CC you there because it seems bugzilla tries to match your name/email with something already present there and doesn't find any match.
https://bugs.winehq.org/show_bug.cgi?id=37202
Simon swdevelop1981@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swdevelop1981@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #5 from Vincent Povirk madewokherd@gmail.com --- I closed the LibreOffice bug because apparently Word on Windows can cope with an entire file range-locked for writing somehow. So this should be fixable in Wine, somehow.
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #6 from Vincent Povirk madewokherd@gmail.com --- Word on Windows seems to cope with this OK (fails after ~2 seconds), but the storage API's my commit modified do not (they fail on Windows after ~20 seconds).
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #7 from Vincent Povirk madewokherd@gmail.com --- Well, I can't figure out how Word is able to detect this situation in 2 or 0 seconds, when in my own testing with StgOpenStorage it takes 20 seconds to fail, and Word doesn't seem to be doing anything special.
I guess I can add the 20 second timeout (which I suspect will mean a 40 second hang in Word, because that's what happens in Word on Windows if I set a read-only lock for the entire file), or I can use read locks to test for this situation in a way that should be compatible with Windows but that I know isn't what Windows does.
I guess I'll try both and see what happens.
https://bugs.winehq.org/show_bug.cgi?id=37202
--- Comment #8 from Vincent Povirk madewokherd@gmail.com --- This should be fixed by 0b7c05389b1c5068077775b50edf620bc3b69084
https://bugs.winehq.org/show_bug.cgi?id=37202
Ruslan Kabatsayev b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #9 from Ruslan Kabatsayev b7.10110111@gmail.com --- Seems to be fixed indeed. Word now gives an error when the file is opened in LibreOffice.
https://bugs.winehq.org/show_bug.cgi?id=37202
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0b7c05389b1c5068077775b50ed | |f620bc3b69084
https://bugs.winehq.org/show_bug.cgi?id=37202
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.39.
-
wine-bugs＠winehq.org