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

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

@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.

@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.

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.

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

@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.

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

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.

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.

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

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

(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.

(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.

Created attachment 121568 [details]
logs for test case open remote file while already opened

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

(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

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

No more info are needed.

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.

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.

This affected all LO supported platforms.

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

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

Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Changing status to NEW.

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

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.

*** Bug 37073 has been marked as a duplicate of this bug. ***

Giuseppe Castagno committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/944853b03bc5a03ee424354669addb4fa9925fbe

ucb: webdav-curl: Related: tdf#96410 eXo Platform WebDAV: where lock fails...

It will be available in 7.3.0.

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

Affected users are encouraged to test the fix and report feedback.

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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug