Bug 96410 - WEBDAV: old version opened after simultaneous open (read only)
Summary: WEBDAV: old version opened after simultaneous open (read only)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.3.0
Keywords:
: 37073 (view as bug list)
Depends on:
Blocks: WebDAV
  Show dependency treegraph
 
Reported: 2015-12-11 12:13 UTC by Tim Banchi
Modified: 2021-04-18 03:49 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
logs for test case open remote file while already opened (21.49 KB, application/x-zip-compressed)
2015-12-27 15:02 UTC, Tim Banchi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Banchi 2015-12-11 12:13:46 UTC
Because lock files are not always deleted on webdav shares, I tried 5.1 beta2 (as #82744 is fixed).
However, if I open one file on two different computers and once the file is locked (and I get the warning that the file is read-only, this computer keeps showing the old version:

Setup:
Webdav server: eXo Platform 4.2, default configuration regarding webdav
Webdav Clients: both have the KB907306 installed and the webdav share is mounted via the "map network drive"
Client 1: Windows 7 32bit, Libreoffice 5.1 beta2 32bit
Client 2: Windows 7 64bit, Libreoffice 5.1 beta2 64bit

Behaviour:
1) Client 1: open and edit document, saves, closes (lock file disappears)
2) Client 2: open, see version after step 1, edits + saves (not close!)
3) Client 1: open, see read only warning, open read only, see version after step 1, close
4) Client 2: close of document
5) Client 1: open, see version after step 1 (wrong version)
6) open the same file with MS Office 2010: see version after step 2 (correct version)
7) view the file in the eXo platform (with document preview): see version after step 2 (correct version)
8) unmount and mount the webdav share again: Client 1 with libreoffice shows still the wrong version

Expected behaviour:
ad 5) see version after step 2 (as MS Office and eXo Platform)

This behaviour makes it very easy to overwrite changes by Client 1 if client 2 has made while the file was (accidentally) opened by Client 1 read-only.

If a file is never opened read-only, a continous workflow between 2 clients shows the correct version.

Tim
Comment 1 Tim Banchi 2015-12-11 12:16:37 UTC
ad Behaviour step 5.5)
If I copy & paste the file on Client 2, the copied file shows the correct version (with updates by Client 2) on Client 1
If I copy & paste the file on Client 1, the copied file shows the wrong version (w/o updates by Client 2) on Client 2
Comment 2 Tim Banchi 2015-12-11 13:54:53 UTC
Because when copying the old version gets copied, I realized it might be a caching problem of webdav. Also MS Office 2010, showing the correct version, asked for login credentials when opening the file (libreoffice did not). I found the Hotfix KB2790804 and installed them on both clients + restart. 

Now, the problem doesn't exist any more but the lock files don't get deleted any more (this was the reason for installing libreoffice 5.1b2). Also, sometimes, even if the file is already closed (and the lock file manually deleted), the file can only be opened read only (both Libreoffice 5 and 5.1b2). The Lock is _not_ showing in the eXo Platform. After 1-2 minutes, the file can be opened normally.


I just tried out the whole procedure with the 2 Windows Clients (LO 5.0.0.5 and LO 5.0.3) and Ubuntu 14.04 (LO 5.0.3.2). Also here the .~lock.XXX files stay after closing LibreOffice. Further I can't (or can I?) change the variable SAL_ENABLE_FILE_LOCKING in Windows as soffice.bin/soffice.exe is not a script. Adding it to soffice.ini doesn't have any effect.

Tim
Comment 3 Alex Thurgood 2015-12-11 15:51:02 UTC
@Tim : does this have anything to do with database files, or were your tests made with a different file type ? The component selector Base if for problems with the database module of LibreOffice.
Comment 4 Tim Banchi 2015-12-11 16:25:58 UTC
@Alex: sorry, no it was writer. I thought "base" is LO base. I moved to Libreoffice as I think this might have to do with the whole Office suite.
Comment 5 Giuseppe Castagno (aka beppec56) 2015-12-17 13:30:55 UTC
Tim Banchi:

I'd like to know what protocol was used to open the file in LO, that can be see looking at the recent file list (e.g. was it file:// or http:// ).

IIRC Word 2010 has a recent file list as well, I'd like to know the protocol of the file there, it this case it can be \\server-name\path (a UNC path) or http://server-name/path.

At a first glance it seems there is something in common with bug 60381 and bug 94888, the two questions above will help me to understand what is.
Comment 6 Tim Banchi 2015-12-17 14:06:58 UTC
Giuseppe,

in LO, I was opening the file from a mounted webdav share (mounted via the "map network drive" in Windows). The path for the windows mount operation is https://..... 
In the LO Recent Documents, if I hover over the filename, I see Z:\documents\test\.... (thus getting the file from the mountpoint I assume).

In Word 2010 however, if I open the recent overview, I see the files with their https://... link.

let me know if I can do something else.

Claus
Comment 7 Giuseppe Castagno (aka beppec56) 2015-12-17 14:32:20 UTC
@Tim:

Can you repeat the tests using https:// proto in LO instead of the mounted path?
This is to see if the LO WebDAV proto works with the WebDAV server you have.
The https:// should be the one Word showed in the recent file list.

You need to enable the LO native file pickers (in Tools > Options > General pane) to use https.

In the tests you did LO used the local file system protocol, with the Windows Web Client service playing the role of man-in-the-middle acting as the 'real' WebDAV interface.
Comment 8 Tim Banchi 2015-12-18 14:36:13 UTC
Hi Giuseppe,

If I open the file directly via LO 5.1b2 (open remote file), there is no .~lock.<filename/> file! However, the file doesn't show locked in the exo platform (no yellow lock sign). The same is true for LO 5.0.0.5 when adding the server there.

I then close the file in 5.0.0.5 and open again via remote file in LO 5.1b2 and then try to open the file while still opened in LO 5.1b2 in MS Office 2010 via the Windows mapped drive (asking me for credentials and using a different user), I get a warning that the file is already opened and I'm able to open a read-only version. 

I then close MS Office 2010 and tried to open the file (still opened with LO 5.1b2 with open remote file) via the Windows mapped drive in LO 5.0.0.5, I can open without a warning. If I than change something in LO 5.1b2 and save it, and than change something in LO 5.0.0.5 and try to save it aswell, I get a warning that the file has changed in the meantime ... Yet there is no yellow padlock showing in exo although the file is opened twice (LO 5.1b2 via remote open, LO 5.0.0.5 via Windows mapped drive).

To test against the first comment: if I now close everything and open the file via the Windows mount in LO5.1b2 or LO5.0.0.5, the file gets again locked (yellow padlock) but also the .~lock.<filename/> file is created (and not deleted after closing LO any more ...)

Tim
Comment 9 Giuseppe Castagno (aka beppec56) 2015-12-18 16:08:09 UTC
Hi Tim,

> 
> If I open the file directly via LO 5.1b2 (open remote file), there is no
> .~lock.<filename/> file! 

that's right, it shouldn't be there, lock in WebDAV works via the dedicated LOCK method.

> However, the file doesn't show locked in the exo
> platform (no yellow lock sign).

that instead looks wrong, but without further info can't say were the wrongness lurks, more on this later.

> The same is true for LO 5.0.0.5 when adding
> the server there.

LO 5.0 code line has a different lock mechanism, better not use it in these tests

> ... open again via remote file in LO 5.1b2
> and then try to open the file while still opened in LO 5.1b2 in MS Office
> 2010 via the Windows mapped drive (asking me for credentials and using a
> different user), I get a warning that the file is already opened and I'm
> able to open a read-only version. 

that means a lock is actually in place, contradicting the absence of a yellow mark on exo,

To shed some light on what's going on, I have a dedicated Windows 32bit logging version of LO that can be used to extract the info I need from the lock operations.

I'll post later on this.
Comment 10 Giuseppe Castagno (aka beppec56) 2015-12-18 16:45:28 UTC
Hi Tim,

the LO version I prepared, adding textual logging to the WebDAV layer, it's a month old, but should be sufficient.

Built it myself, it's derived from master branch, you may download it from here:

http://www.acca-esse.it/dwnld/lo/LibreOfficeDev_5.1.0.0.alpha1_Win_x86_en-US_it_fr_de_qtz.msi

The source code of this specific version is in github:

https://github.com/beppec56/core/commit/eaa7856aa68355db39d16eca93a9cada0cee63e3

Install following the instruction here:

https://wiki.documentfoundation.org/Installing_in_parallel/Windows

I'd suggest you use the SI-GUI application:

https://wiki.documentfoundation.org/Installing_in_parallel/Windows#SI-GUI

when installed, you may start it and do these tests, enabling the LibreOffice dialogs:

1) open a file in LO using remote file dialog, using the https:// address, then close the file

2) open a file with Word 2010, than open the same file from LO close the file in LO.

Then close LO to save all the logs generated during the run phase.
The logs, in textual form, with the installation folder as in
C:\test-lo\lo5100a1 folder, are available in the following folder:

C:\test-lo\lo5100a1\user\logs

They are saved in textual Linux format so to open them you need an editor like Notepad++:

https://notepad-plus-plus.org

Before posting the logs, have a look to see if they contain any sensible  information, edit them if you find it necessary.

Then zip and attach here.

Alternatively, you may send them to me privately, I'll post here only the relevant part.

Thanks.
Comment 11 Tim Banchi 2015-12-25 12:32:56 UTC
I'm sorry for the late reply Giuseppe. I've to use another computer as I cannot access my work computer during holidays. It is a Windows 7 Starter, but I hope it is still fine for testing.

Unfortunately I didn't even get to open a file via the open remote file dialog. LO constantly forgets port, secure connection checkbox and username. I tried numerous times and I always have to reset those fields and I assume when choosing the connection from the dropdown (in the open remote dialog) or double clicking it from the left pane in the open dialog, it might try to connect with the wrong settings (I just see the windows "busy" icon as my mouse cursor for a while, that's it). It was already not working well in the LO5.1b2 version but I did eventually manage after some time.

Can you write me the configuration file location for the webdav/remote server configuration, so I can set it manually? I didn't find anything in the AppData folder nor online. I can then try to test.

Also, after opening files via the windows mapped drive and closing LO, I don't see any C:\test-lo\lo5100a1\user\logs folder or files. I find logs however under C:\Users\Administrator\AppData\Roaming\LibreOfficeDev\4\user\logs. Are those the relevant logs?

And what about the problem of the ~.lock files when opening a file via the Windows mapped drive? Can the creation of this file somehow be surpressed?

Tim
Comment 12 Tim Banchi 2015-12-25 14:31:32 UTC
If I try to copy the full link to the file into File->Open->File Name I get a "Could not establish Internet connection to <domain/>." (got that from https://help.libreoffice.org/Common/Opening_a_Document_Using_WebDAV_over_HTTPS). The link works just fine with Firefox or Windows mapped drive.

Couldn't I try the lastest beta and enable necessary debugging by starting it up with some parameters?

Tim
Comment 13 Giuseppe Castagno (aka beppec56) 2015-12-25 16:00:33 UTC
(In reply to Tim Banchi from comment #12)
> If I try to copy the full link to the file into File->Open->File Name I get
> a "Could not establish Internet connection to <domain/>." (got that from
> https://help.libreoffice.org/Common/
> Opening_a_Document_Using_WebDAV_over_HTTPS). The link works just fine with
> Firefox or Windows mapped drive.

You ticked the checkbox 'Use LibreOffice dialogs', don't you?

With eXo PF4.2 I installed in a VM in the mean time, I used a path like this:
http://192.168.1.82:8080/rest/private/jcr/repository/collaboration
to reach the folder where I have test files.
PF4.2 is the standard community version, no custom configure.

> 
> Couldn't I try the lastest beta and enable necessary debugging by starting
> it up with some parameters?

There is a RC1 available, from here:
http://download.documentfoundation.org/libreoffice/testing/5.1.0/win/x86

but the logs are something I set on my own to help me to solve problems with my customers using LO, it's not available on vanilla LO.
Comment 14 Giuseppe Castagno (aka beppec56) 2015-12-25 16:48:38 UTC
(In reply to Tim Banchi from comment #11)

...

> 
> And what about the problem of the ~.lock files when opening a file via the
> Windows mapped drive? Can the creation of this file somehow be surpressed?
> 

It's possible, in 'Expert Configuration', see:
https://help.libreoffice.org/Common/Expert_Configuration
Locate UseLocking property and set it to false.

In doing so you won't have the lockfile for local file, easily ending in trouble if working locally or with network mounted units sharing file.
In case you need it, you will lose the Calc shared file feature as well.

Microsoft Office applications do something different wrt LO when dealing with WebDAV mounted partition, see here:
http://blogs.msdn.com/b/brian_jones/archive/2006/02/17/534142.aspx
for a description.

I'm afraid LO doesn't work that way.
Comment 15 Tim Banchi 2015-12-27 15:02:51 UTC
Created attachment 121568 [details]
logs for test case open remote file while already opened
Comment 16 Tim Banchi 2015-12-27 15:05:45 UTC
I managed with your built, before the local firewall blocked. Both times I opened via the remote file open feature of LO. The second time I didn't get warned that the file already was open (and in edit mode) by Word 2010.

Tim
Comment 17 Giuseppe Castagno (aka beppec56) 2015-12-28 11:11:53 UTC
(In reply to Tim Banchi from comment #16)

> ..... The second time I didn't get
> warned that the file already was open (and in edit mode) by Word 2010.

You were not warned simply because LO didn't attempt to put a lock, apparently eXo PF4.2 doesn't implement a mandatory feature of WebDAV (RFC4918).
It doesn't implement the 'supportedlock' property. LO uses it to detect if the LOCK method can be issued.

See here for details about 'supportedlock':
<http://tools.ietf.org/html/rfc4918#section-6.7>, relevant excerpt:
'...Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property...'

I found it in the logs you send, this is a payload received in response to a supportedlock request issued by LO:

<?xml version="1.0" ?>
  <D:multistatus xmlns:D="DAV:" xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">
     <D:response>
       <D:href>https://DOMAIN:443/rest/private/jcr/repository/collaboration/Groups/spaces/testspace_2/Documents/test/newsletter.docx</D:href>
       <D:propstat>
        <D:prop><D:supportedlock/></D:prop>
        <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
  </D:multistatus>

eXo pf 4.2. response is 'Not Found' for that property.

Unfortunately this rules out the possibility of working with eXo in native WebDAV mode, for the time being.

I'm repeating the tests you did in bug description, I got two Windows 7 32bit system, installed eXo PF4.2 community edition to carry out that.
I'll use
Comment 18 Tim Banchi 2016-02-08 18:07:16 UTC
Thank you Giuseppe,

same behaviour in eXo 4.3. Very unreliable locking.

I filed a bug report here https://jira.exoplatform.org/browse/ECMS-7402

For the time being we have to use MS Office and thus Windows, what a pity.

Tim
Comment 19 Giuseppe Castagno (aka beppec56) 2016-07-30 17:21:53 UTC
No more info are needed.
Comment 20 Commit Notification 2016-08-01 06:05:27 UTC
Giuseppe Castagno committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4475c191de479e7a5ddb20d14bc3aa32b0ab84d3

Related: tdf#96410 eXo Platform WebDAV: where lock fails...

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Giuseppe Castagno (aka beppec56) 2016-08-02 08:09:47 UTC
Tim,

I finally managed to have LO working on eXo on standard http and https protocols.

When you can have a look at it, the current daily master, can be downloaded from here:

http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current

just repeat the test you did to check locks in interaction with Word.

While opening the file from a mounted webdav share LO treat the file as if it were on the local file sistem, so the lock/unlock and all other interaction to webdav server is carried out by the Windows driver concerned.
Comment 22 Giuseppe Castagno (aka beppec56) 2016-08-02 08:10:27 UTC
This affected all LO supported platforms.
Comment 23 Giuseppe Castagno (aka beppec56) 2016-08-02 08:12:26 UTC
Tim,

Forgot to mention that this procedure can be of help on testing the master:

https://wiki.documentfoundation.org/Installing_in_parallel/Windows#SI-GUI
Comment 24 Tim Banchi 2016-08-02 08:26:05 UTC
Dear Giuseppe,

thank you very much for the fix, I will test as soon as possible, I hope next week, and will comment here.

Tim
Comment 25 Xisco Faulí 2016-09-26 11:11:20 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Changing status to NEW.
Comment 26 Tim Banchi 2016-10-18 14:16:45 UTC
Hi Giuseppe,

I tried the following scenarios with libo-master~2016-10-18_03.24.21_LibreOfficeDev_5.3.0.0.alpha0_Win/Linux

PC1 with Win7 and LO 5.3 and MS Office 2010
PC2 with Win7 and LO 5.3 and MS Office 2010
PC3 with CentOS 7.2 (latest) and LO 5.3 and davfs2 v1.4.7

Test A with Windows Explorer Mapping on both PCs (different usernames)
1) Open file X on PC1 with LO 5.3 -> OK
2) Open file X on PC2 with LO 5.3 -> warning that the file is already opened by myself (while I connect with different usernames to the mapped drive)

Test B with Windows Explorer Mapping (different usernames)
1) Open file X on PC1 with MS Office -> OK
2) Open file X on PC2 with LO 5.3 -> warning that the file is already opened by myself (while I connect with different usernames to the mapped drive)

Test C with Windows Explorer Mapping (different usernames)
1) Open file X on PC1 with LO 5.3 -> OK
2) Open file X on PC2 with MS Office -> warning that the file is already opened _by another user_

Test D with Windows Explorer Mapping (PC1) and davfs/gvfs mount (PC3) (different usernames)
1) Open file X on PC1 with LO 5.3 or MS Office -> OK
2) Open file X on PC3 with LO 5.3 -> NOT OK because no warning is given

Test E with Windows Explorer Mapping (PC1) and LO 5.3 open remote dialog (PC3) different usernames
1) Open file X on PC1 with LO 5.3 or MS Office -> OK
2) Open file X on PC3 with LO 5.3 remote open dialog -> OK and warning given that file is opened, correct user is shown

Tests A and B are completely fine when the file is opened with the LO remote open dialog (correct users who are currently editing are shown)

so it seems the LO side is fine (except that not the correct user is found who has opened the file).

kind regards,
Tim
Comment 27 Xisco Faulí 2017-09-11 08:36:58 UTC
Dear developer,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 28 Xisco Faulí 2017-10-17 08:25:36 UTC
*** Bug 37073 has been marked as a duplicate of this bug. ***
Comment 29 QA Administrators 2019-04-18 03:04:03 UTC Comment hidden (obsolete)
Comment 30 QA Administrators 2021-04-18 03:49:02 UTC
Dear Tim Banchi,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from https://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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug