Windows XP with Microsoft Office 2007 and a shared directory with CIFS or SMB. Ubuntu 14.04 accessing the shared directory remotely (Unity/GNOME guess using GVFS?). Steps: - from Ubuntu open the .xls spreadsheet with LibreOffice 4.2.7.2. - from Windows open the same .xls spreadsheet with Office 2007 without warning. Another test: - from another Windows XP open the .xls spreadsheet with LibreOffice 4.2.dontrememberexactly from the network share. - from Windows open the same .xls spreasheet with Office 2007 without warning. Reversing the steps works correctly, I mean: - from Windows open the .xls spreadsheet with Office 2007. - from Ubuntu opening the same .xls with LibreOffice shows that it is already opened. The user with Office 2007 opens the file locally. Thanks for looking into this. Have a great day!
I can confirm with LO Version: 4.5.0.0.alpha0+ Build ID: 51e0d789c344547956764c3b5f0ef5a304f4e0aa TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-13_16:58:45 and excel 2010 The same with .xlsx. I can write with excel into already opened file in linux.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Tamas, I CC-ed you because you are making this https://gerrit.libreoffice.org/#/c/69582/
Writing MSO lockfiles is implemented in https://git.libreoffice.org/core/+/5db1e20b8b0942dac2d50f3cd34532bb61147020 https://git.libreoffice.org/core/+/41dc917b9b55b8c0c4307ffc58a1fb7257df2b69 https://git.libreoffice.org/core/+/ad47e9b1c0d3f1720665b2786090e8c0927b5b45 A dedicated configuration option "[ ] Create MSO lock file" on Options->Load/Save->Microsoft Office dialog controls this. Closing RESOLVED FIXED. Tamás Zolnai, thank you!
Hello. Thanks into looking this issue. Every LibreOffice user has to activate the "Create MSO lock file" option in order to correctly interoperate with Excel users? Whats the drawback of having that option always activated? Thanks a lot for the info!
(In reply to Iván Baldo from comment #5) It's not "you need to do something to correctly interoperate with MSO". That statement shifts the view to look like some LibreOffice deficiency. LibreOffice uses its own lockfiles, inherited from OOo. And those files are not read by MS Office, so MS Office does not know LibreOffice uses a file. When there's no file-system-level locking somewhere, it might result in different applications being able to open a file for writing, and file system does not prevent that. So lock files allow an application (its different instances) to workaround that filesystem problem. But lockfiles are application-specific thing, not standardized in any way. As users wanted LibreOffice to report who opened a file using MS Office, LibreOffice was improved to be able to read MS Office lockfiles [1]: that is of course something LO needed to do. But when MS Office users wanted their MS Office to show when LibreOffice opened a document - exactly symmetrical operation - it would be logical that they asked MS Office to improve. Well - of course, no matter what, it must be LO fault! ;-) - so instead, this bug appeared; and we even decided to introduce additional complexity and teach LO to *write* MSO lockfiles. LibreOffice did this job, instead of MSO that should have learned to read LO lockfiles. What is the drawback? First - MSO lockfiles are not standardized; and we reverse-engineered them, which means we can not be totally sure that we write correct format. Which, in turn, night potentially mean some issues on MSO side. Next, in case of LO crashes, two sets of lockfiles would stay instead of one; and while we implemented a way to optionally ignore stalled lockfiles in LO, there might be not equivalent option in MSO, which could mean MSO users would be unable to open documents after LO crash. [1] https://git.libreoffice.org/core/+/607b80ca3cddc239a35580470944a438ce144fc8
So LO when opening an MSO file writes 2 lock files? One in the MSO format and another in the LO format? Of course everyone has his opinions on how to do things, it seems we don't agree on that, which is fine too. Though let me clarify what is my personal opinion, just for clarity: "LO when opening MSO files should act as much as possible as if MSO was opening MSO files." That's for interoperability, which I think is good in order to start introducing LO gradually in a business without a 0 to 100% switch (which most business would not take the risk to do it that way). The XLS format and others where reverse engineered AFAIK, there was a reason for that and I bet it was a pain to do, but is needed even today, reverse engineering the MSO locking files and procedures is just part of that same equation and effort. If MS doesn't specify the format of its locking files, just pester them on Twitter, you know... they are "open source friendly" now... (which I just don't believe but anyway...), in fact I just did: https://twitter.com/ivanbaldo/status/1114548634782195713 Thanks a lot for doing this work, even if we don't agree on the default behavior.
(In reply to Iván Baldo from comment #7) > So LO when opening an MSO file writes 2 lock files? > One in the MSO format and another in the LO format? Yes.