Bug 90678 - Microsoft Office 2007(2010) Excel opens already opened .xls and .xlsx file with LibreOffice
Summary: Microsoft Office 2007(2010) Excel opens already opened .xls and .xlsx file w...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Tamás Zolnai
Whiteboard: target:6.3.0
Keywords: filter:xls, filter:xlsx
Depends on:
Blocks: XLSX XLS File-Lock
  Show dependency treegraph
Reported: 2015-04-17 15:03 UTC by Iván Baldo
Modified: 2019-04-06 15:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Iván Baldo 2015-04-17 15:03:09 UTC
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?).
- from Ubuntu open the .xls spreadsheet with LibreOffice
- 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!
Comment 1 raal 2015-04-18 18:51:05 UTC
I can confirm with LO Version:
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.
Comment 2 QA Administrators 2016-09-20 09:24:48 UTC Comment hidden (obsolete)
Comment 3 Roman Kuznetsov 2019-03-24 11:06:30 UTC
Tamas, I CC-ed you because you are making this https://gerrit.libreoffice.org/#/c/69582/
Comment 4 Mike Kaganski 2019-03-30 18:28:53 UTC
Writing MSO lockfiles is implemented in


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!
Comment 5 Iván Baldo 2019-04-06 13:18:50 UTC
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!
Comment 6 Mike Kaganski 2019-04-06 13:40:21 UTC
(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
Comment 7 Iván Baldo 2019-04-06 15:24:02 UTC
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:

Thanks a lot for doing this work, even if we don't agree on the default behavior.
Comment 8 Mike Kaganski 2019-04-06 15:31:59 UTC
(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?