Why does NUxeo Drive not lock documents, when they are opened for editing? Files are locked when opened via WebDAV

If I establish a WebDAV connection to Nuxeo, and then edit a file in MS Word 2007, the file shows as 'locked' on the website. However, if I establish the connection via Nuxeo Drive, and edit the file in MS Word, it does NOT show as locked. It would seem desirable to lock the file, regardless of the specific connection type. And it seems like Nuxeo Drive, as an installed application, would be the 'more capable' connection method.

FYI- I'm using super current on everything except MS Word. I downloaded the Nuxeo VMWare image about 2 days ago, and I've customized nothing.

1 votes

1 answers

726 views

ANSWER



Hello,

It's an interesting point you got there. Indeed such behaviour is not implemented in Drive because we have no way, for now, to detect that a file is opened by an application such as MSOffice. In the case of WebDAV, this is native: editing a doc with MSOffice locks it a the file system level (marking it as readonly), this event is detected by the WebDAV client which sends the lock command to the server. In the case of Drive, we don't have a file system notification mechanism (we only look for local changes every 5 seconds) which would be the only way to be informed that a doc has been locked by an application to then be able to call the lock operation on the server. This need is partially tracked by https://jira.nuxeo.com/browse/NXP-9583 which has not been scheduled yet.

Note that the file system locking depends on the OS / file system / program, so in any case this behaviour could not be guaranteed in 100% of the cases, but in the standard one (Windows / MSOffice) it would work.

In any case, Drive handles conflicts so possible concurrent edition should not be blocking.

Finally, setting aside the technical aspect, this is a functional choice which doesn't necessarily fit every use case, so this feature would be an option.

1 votes



Wow that is an awesome answer.

Thinking about it in more detail, I now see that opening a file doesn't always indicate a desire to edit. Maybe they are just reading the file. For me, I would prefer to always lock. But I can see how not all users would want that behavior.

Thanks for your answer!

09/26/2013

Interesting. I'll just add my two cents :

  • there's already some work on multiplatform inotify+sync feature, in Owncloud's sync client (the interesting parts are call mirall and csync, IIRC). You may be aware of that already, but it could be a convenient basis for some future version of Drive (provided one adds the "communication" channel actually used by Drive to allow "live-edit"-like behaviour).
  • does the "edit through drive" action in the web interface lock the file? If not - and I'd say it should be, since we usually use that when ACTUALLY editing the file - it could be sensible to add a second action, which does the "lock+edit+unlock" thing. But then again, I guess it's already the default behaviour.
09/26/2013

Thanks for the pointers to mirall and csync, we'll definitively have a look. Currently the Drive Edit action doesn't lock the document, I agree thet such a behaviour would be nice, again probably as an option of the nuxeo-drive addon. Technically in this case there is no problem as an edition event is triggered server-side. You can watch the Nuxeo Drive backlog to be aware of the next user stories to come. There is already one about document locking: https://jira.nuxeo.com/browse/NXP-10133 which I've updated to take into account the use case you are describing.
09/27/2013

rg1
If you really want server-side locking semantics vs. Nuxeo Drive concurrent edition conflict management, you might consider using the alternative Nuxeo CMIS interface which is now natively supported by MS Office, LibreOffice, etc.
09/27/2013

Alfresco (I used that system before Nuxeo) uses the Sharepoint protocol for what they call "Direct Edit", might also be a way to go.
01/30/2017