When I try to open a document in MS Word (run via Wine), having it open in LibreOffice Writer, Word hangs. I've reported this to Wine . The developer answered:
> 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 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).
So this also seems to affect real Windows-based Word when accessing file on a network share. The Wine developer also suggests the following:
> 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.
See more details of the discussion in the Wine bug report at .
For the record, I use a samba server on a centos box to share files on my computers. Typically I edit using Fedora 21 and Windows XP.
I have never seen this problem and get the impression from the Wine guy that the problem will only be seen when using wine. I think it is worth nutting out a procedure though. How does this sound:
1. Create a file (.DOC or .DOCX) using LO under linux copy to network share
2. Modify file using LO from network share and write back
3. Try to access the file with windows PC using word
4. Try to access the file with linux PC & wine using word
Steps 3 & 4 should be successful. The problem is recreated if there is a problem at 3 or 4
The procedure you describe would only test Wine and your network filesystem (but it would be a good test for those things). Step 4 should show that someone else has the file open for writing and Word will only open it in read-only mode.
Also, this only applies to .DOC files, not .DOCX.
I have not tested this scenario but I am guessing you will see the problem without Wine if you follow this procedure:
1. Create a .doc file in LO on Linux and save it to the network share.
2. With the .doc file on the network share still open in LO on Linux, try to access it in Word on Windows.
The ideal result of step 2 would be to get a warning that someone else has the file open for writing, but I don't think it's reasonable to expect that level of compatibility from LO. Locking only the bytes I mentioned should prevent Word from opening the file at all. I suspect that currently step 2 will hang word until LO has closed the file.
- Using LO under Fedora I open a .DOC file (from the samba share).
- Now over to XP where I attempt to open this file with MS Word 2007.
- I initiate this access from windows explorer
- Word cranks up and I get a message "Could not open..."
- Acknowledge this message and close the file over on Fedora
- Back to XP, open the file - all good
I tried a few different approaches. Word open and closed before access. And pulling the file out of "recent documents" but each time I got the "could not open..." message
(In reply to Tim Lloyd from comment #3)
> I tried a few different approaches. Word open and closed before access. And
> pulling the file out of "recent documents" but each time I got the "could
> not open..." message
Where are we with this bug report? Sounds like you can't repro?
Can the Wine Devs help out with testing here?
I need to do some investigation wrt how network shares map locking semantics between Unix and Windows. Tim's results show that this doesn't happen the way I expected, and I need to make sure it doesn't break Wine in other situations not involving LO. (Specifically, if CreateFile share modes are being mapped to a range lock on the entire file, this will cause Wine/Word to hang trying to open a file that Windows/Word has open. Which would also prove it's not your bug.)
To be clear, the originally-reported bug is a hang involving Wine/Word and Linux/LibreOffice running on one machine. The scenario Tim tested was an attempt to show that the bug can be reproduced without Wine, and it didn't show that. So right now there's a bug when using Wine and LibreOffice together, and I don't know for sure which project needs to be fixed (but I'm current leaning towards Wine).
(In reply to Vincent Povirk from comment #6)
> So right now there's a bug when using Wine and LibreOffice
> together, and I don't know for sure which project needs to be fixed (but I'm
> current leaning towards Wine).
Yep, that was my understanding :-) Sounds like we're pretty confident about this issue, so Status -> NEW.
I'll also update the Summary to make things clearer.
Created attachment 113841 [details]
test program that prints currently-open range locks on a file
I wrote a quick test program (attached) to check what range locks are open on a file. For a .doc file opened by Word 2013 on real Windows through samba (version 2:3.6.6-6+deb7u5), it shows me this:
write lock start 2147483539 len 1
write lock start 2147483559 len 1
write lock start 2147483599 len 1
For a .doc file opened locally in Libreoffice writer, it shows this:
write lock start 0 len 0
This is roughly what I expected.
For completeness, I also tried the 'flock' command, and it succeeded in taking an exclusive lock in both cases.
I still have to do a test opening the same file with both, which requires setting up NFS to the server running samba.
I did the test using NFS and Samba. Word can tell immediately that the file is open in LibreOffice, and I cannot figure out how. If I lock the entire file for writing, using fcntl, I get the same result.
If I lock the entire file for writing using LockFileEx (it does not provide a way to lock the entire file), Word detects this after a few seconds. I cannot figure out how it's possible to tell the difference between this and fcntl using the Windows API.
I hate that I don't understand that difference, but even in the worst case scenario (given what LO is doing) we should only hang for a few seconds. So I'm going to say it's a Wine bug.
Sorry, in my tests I was locking the first 2**63-1 bytes, so that I could compare directly with LockFileEx which doesn't seem to be able to lock the entire file.