Bug 113033 - No error message when trying to save a locked document from a SMB external storage in Nextcloud with Collabora Online
Summary: No error message when trying to save a locked document from a SMB external st...
Status: NEW
Alias: None
Product: LibreOffice Online
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Error-Messages
  Show dependency treegraph
 
Reported: 2017-10-10 09:38 UTC by Philippe Hemmel
Modified: 2018-12-18 07:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Hemmel 2017-10-10 09:38:39 UTC
### Steps to reproduce

SMB external storage needed in a Nextcloud configuration, with Collabora Online on the same server.

1. User A opens the document test.odt directly on the windows server or from a network drive or from a UNC path, with LibreOffice. 
a `.~lock.test.odt#` file is created in the same folder.
2. User B opens the same document with Collabora Online from a SMB external storage in Nextcloud, whatever the type of authentication used
3. User B modifies the document and save it (the document is still open by user A with LibreOffice)

### Expected behaviour

User B should receive a error message because the document is locked on the server and B can't save it

### Actual behaviour

B can save the document and exit Collabora Online without any warning, but all the modifications made by B will be lost.

The admin_audit app logs "File updated" and then "File written", which is false.

Not sure if it's a Collabora Online or Nextcloud bug, but as Nextcloud manages the storage, I think that Nextcloud should do the job.
### Steps to reproduce

SMB external storage needed

1. User A opens the document test.odt directly on the windows server or from a network drive or from a UNC path, with LibreOffice. 
a `.~lock.test.odt#` file is created in the same folder.
2. User B opens the same document with Collabora Online from a SMB external storage in Nextcloud, whatever the type of authentication used
3. User B modifies the document and save it (the document is still open by user A with LibreOffice)

### Expected behaviour

User B should receive a error message because the document is locked on the server and B can't save it

### Actual behaviour

B can save the document and exit Collabora Online without any warning, but all the modifications made by B will be lost.

The admin_audit app logs "File updated" and then "File written", which is false.

Not sure if it's a Collabora Online or Nextcloud bug, but as Nextcloud manages the storage, I think that Nextcloud should do the job.

So the bug is also created here : https://github.com/nextcloud/server/issues/6804
And I create this one to follow up.

### General server configuration

**Operating system:** Linux 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 x86_64

**Web server:** Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/7.1.5 (fpm-fcgi)

**Database:** mysql 5.5.52

**PHP version:** 7.1.5

**Nextcloud version:** 12.0.2 - 12.0.2.0

**LibreOffice Online version:** Collabora Online 2.1.3

**Windows server:** Windows server 2012 R2

**Are you using external storage, if yes which one:** 
    [0] => \OC\Files\Storage\Local
    [10] => \OCA\Files_External\Lib\Storage\SMB

**Are you using an external user-backend, if yes which one:** 
OpenLdap + Active Directory
Comment 1 Joel Madero 2018-12-07 03:42:44 UTC
@Michael - I rarely add you to a cc on a bug without first asking but this one seems like one you'd find interesting (possibly) and have knowledge about.

It's quite old, trying to deal with these old unconfirmed bugs.

Thoughts?
Comment 2 Michael Meeks 2018-12-07 09:22:21 UTC
First - Joel ! wonderful to see you again - hope all's well; would love to catch up.

Second - distributed locking is a living hell. Even if making this rather complex use-case possible was something we could do easily (and that's far from clear - it's a mixed Nextcloud, Online issue) - we would then get a slew of other bugs and use-cases around leaked lock-files; whether Nextcloud should try to create lock files when it believes a document is open in Online (but only when that is un-modified? rather than waiting for an hour to be expired?) etc. - the area opens a enterprise-sized can of worms =)

Some of the reasons why I've resisted getting involved in distributed locking at least ;-) and that's before we get into leaked locks, inconsistent locks (where there is an OS/SMB lock on the file, but no lock-file or vv.) and so on ... anyhow.

It is possible we can improve this with some concerted effort; in theory WOPI has locking extensions that can be implemented, but ... its a massive job to get right, horribly hard to validate, and will inevitably be deeply disappointing.

I'd prefer FWIW to work on more robust ways of visualizing and/or merging changes ;-) now that is something generally useful & interesting.

Nevertheless - we should prolly keep this open, in the long run we may have to do something here.

Philippe - how are you feeling about this ? and/or do you feel motiviated to come up with a big matrix / description of the cases we need to handle (including all the asynchronous races between each of those - it will be many tens of different stats)  - and what we need to do in those cases.