Summary: | Linux version of LibreOffice locks open documents in a way incompatible with MS Word running on Wine | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Ruslan Kabatsayev <b7.10110111> |
Component: | Libreoffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | lowest | CC: | madewokherd, qubit |
Version: | 4.0 all versions | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | needsWine | ||
i915 platform: | i915 features: |
Description
Ruslan Kabatsayev
2014-08-30 18:04:05 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.