WebDAV locking

[jmbreuer]

I recently upgraded from LibreOffice 4.0.4.2 to 4.1.2.3 (Linux x64).

With LO 4.0, editing of documents in Alfresco via WebDAV worked in principle; one could open and save existing documents, versioned documents would get a new version on save.
Creating a new document from LO 4.0 via WebDAV was not possible ("resource does not exist").


Now with LO 4.1, editing via WebDAV is no longer possible in any useful way.
Opening a document via WebDAV works as expected, but trying to save the changed documents leads to "The file <file> is locked by yourself. Currently, another write access to this file cannot be granted."
Closing/Opening LO 4.1 and opening the same file again then leads to "The file <file> is locked by another user. Currently, another write access to this file cannot be granted."

I see no way to reset this lock from Share or the Alfresco Explorer.


Saving a file from LO 4.1 via WebDAV is possible when the Alfresco instance is restarted after opening, but before saving a file.

Creating new files is possible using LO 4.1.


This affects Alfresco 4.2c as well as Alfresco 4.2e (community edition).

Until this is fixed properly, is there a way to run Alfresco in "cowboy mode" with WebDAV locking disabled (i.e. "last save wins")?


After these issues I've also had a look at CMIS mode, the cmisatom looks allright when I download it using curl but LO 4.1 does not show a Repository to be selected, so the CMIS setup dialog cannot be completed.


I'll be happy to assist in debugging; is there a way to get detailed WebDAV logging out of Alfresco?

[ebogaard]

While in 4.2c we didn't experience webdav locking problems, they returned in 4.2e.
Up until now, we only have seen this with MS Office documents and applications.
The suggested 'cowboy mode' seems appealing as a back-up, as you can always choose to 'Edit Offline' to lock a document.

[jmbreuer]

<blockquote>
I see no way to reset this lock from Share or the Alfresco Explorer.
</blockquote>

Actually, <strong>now</strong> I do.

Apparently, my browsers had an older version of the Share UI resources cached, which did not contain/show the "Cancel editing" option <em>ever</em>.

<strong>Weeks</strong> after the last update/change to Alfresco I yesterday logged into the Share UI as usual and was greeted with an updated UI layout, and in this updated layout the "Cancel editing" option is available and works as expected.

Lesson learned: Refresh/sanitize the browser cache after upgrading Alfresco.

Sort-of-only-half-on-topic: Is there a mechanism that can tell user's browsers to refresh the resources in this case (i.e. <strong>correct</strong> use of If-Modified-Since etc.)? For larger deployments "telling the users to clear their browser cache" is not a practical solution.

Of course, "Cancel editing" via Share UI is only a workaround in the first place. The WebDAV locks set by LibreOffice remain in place when the document is closed in LO.

Also, when a document is opened as read-only in LibreOffice (special option directly in the "Open" dialog, used to work as expected some time in the past) apparently an exclusive lock is set in Alfresco.

My query on how to get verbose WebDAV locking logging out of Alfresco still stands; that would help to trace down what exactly is handled incompatibly between LO and Alfresco.

[jmbreuer]

Another observation:

Share will not always show that the file is locked and offer the cancel editing function.

But in these cases, I could always "edit offline" (cancelling the download) and "cancel editing" immediately afterwards; after that access to the document via WebDAV is also possible again.

This points toward another problem/bug, apparently "edit offline" is capable of breaking (at least the hung variant of) WebDAV locks…

[rob562435]

Using oXygenXML Author as editor to modify a DITA topic in Alfresco Community version 4.2e via the WebDAV interface I encountered something similar. When opening the DITA file a lock is created in Alfresco with a timeout of 300 seconds. While the file remains open in oXygen every 150 seconds a "relock" request is sent to Alfresco with the purpose to extend the timeout with 300 seconds. Still after the first 300 seconds Alfresco seems to remove the lock due to the timeout of the first request, thereby showing that relock requests are ignored. Still neither in logging nor in any traffic an error is thrown towards oXygen. Looks related to the above…
Setting Debug options for WebDAV gives more information but also does not indicate any error, just acceptance of the WebDAV lock requests… Unfortunately I did not find a way to get the part of logging needed to get info on what actually happens with the lock…