Bug 90249 - LibreOffice cannot open file on webdav server with windows 7 Operating system
Summary: LibreOffice cannot open file on webdav server with windows 7 Operating system
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: Other Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0
Keywords: notBibisectable, regression
Depends on:
Blocks: 95792
  Show dependency treegraph
 
Reported: 2015-03-26 09:54 UTC by lnunes
Modified: 2016-10-25 19:21 UTC (History)
6 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 lnunes 2015-03-26 09:54:06 UTC
I used openkm as cmis server.
With LO, I browse my webdav server and select a file which is not already locked for opening.

Expected result: 
1- file is opened 
2- a lock is put on webdav server for this file.

Actual result: 
1- file is not opened. (error message in french is: le fichier  ... est vérouillé par un autre utilisateur. Actuellement un autre droit d'écriture à ce fichier ne peut pas être accordé. This means : file cannot is locked by another user. Another write access to the file cannot be given).
2- lock has been put on file by me.

As a result, I cannot open any file on my webdav server.

Problem is seen on my LO on windows with release version 4.4.0.3
But this is not reproduced on linux ubuntu with LO version 4.2.7.2
Comment 1 Matúš Kukan 2015-04-14 06:54:01 UTC
Can't reproduce on Windows 8 with LibreOffice 4.4.1.2 accessing files on ownCloud server.
Comment 2 lnunes 2015-04-14 08:15:33 UTC
(In reply to Matúš Kukan from comment #1)
> Can't reproduce on Windows 8 with LibreOffice 4.4.1.2 accessing files on
> ownCloud server.

Hi Matúš
I still reproduce it with LO 4.4.2.2 using windows 7 and openkm server 6.3.0
How Can I help you to investigate? (software with traces that I could send back to you?)
Thanks.

lnunes
Comment 3 lnunes 2015-04-17 14:43:44 UTC
Hi Matus.

I have downloaded version 4.2.7.2 for windows (I have windows 7 installed on my PC).
It turns out that file cannot be opened on webdav server and lock has been put.
My colleague also has 4.2.7.2 but running on linux. It works fine for him: lock is put and file is coorectly opened.

So this is not a regression but an issue linked to OS version. I updated the bug summary accordingly.
Comment 4 lnunes 2015-04-17 14:45:07 UTC
Hi Matus.

I have downloaded version 4.2.7.2 for windows (I have windows 7 installed on my PC).
It turns out that file cannot be opened on webdav server and lock has been put.
My colleague also has 4.2.7.2 but running on linux. It works fine for him: lock is put and file is coorectly opened.

So this is not a regression but an issue linked to OS version. I updated the bug summary accordingly.

Regards

Licinia
Comment 5 lnunes 2015-04-27 13:53:57 UTC
Hi Matus.

Is there any news on your side for this subject?
What do you suggest to do?
THnaks a lot.
Best regards.
Comment 6 Giuseppe Castagno (aka beppec56) 2015-10-29 13:46:36 UTC
(In reply to lnunes from comment #5)

> Is there any news on your side for this subject?
> What do you suggest to do?

lnunes:

I worked on LO WebDAV interface recently, namely the lock/unlock mechanism, LO 5.1.0.0-alpha1 contains the changes.

If you find the time, please download it from here:

http://dev-builds.libreoffice.org/pre-releases/

I'd like to know if something changed for you.

Thanks.
Comment 7 Giuseppe Castagno (aka beppec56) 2015-10-29 13:59:11 UTC
lnunes:

I forgot to mention that LO 5.1.0.0-alpha1 is a pre-release version, non meant for production work.

You may install it following the instructions here:

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

I think the easier method in Windows is using this application:

https://flosmind.wordpress.com/si-gui/

In this way you won't break your main LO configuration, a separate empty one will be used.
Comment 8 lnunes 2015-11-02 09:56:12 UTC

Hi Giuseppe.

Thanks for the tip of parallel LO installation: this is very convienent
I tried with the version 5.1.0.0-alpha1 (x64).
I still have the same behaviour: when I try to open a file, message displayes that file is locked. And when I check on openKM, file is effectively locked.
So no change on my side with this new LO version when using openkm server 6.3.
Comment 9 Giuseppe Castagno (aka beppec56) 2015-11-02 14:24:44 UTC
(In reply to lnunes from comment #8)

lnunes:

> I tried with the version 5.1.0.0-alpha1 (x64).
> I still have the same behaviour: when I try to open a file, message
> displayes that file is locked. And when I check on openKM, file is
> effectively locked.

is it LO that shows a 'file locked' message?

> So no change on my side with this new LO version when using openkm server
> 6.3.

where can I download a free version of openkm 6.3 WebDAV server?

I'd like to set up a 'test rig' to reproduce your problem.
Comment 10 lnunes 2015-11-02 14:43:50 UTC
Hi Giuseppe.

Lo shows the lock message: "Le document XXX est verrouillé pour édition par: 
XXXX 
Ouvrez le document en lecture seule ou ouvrez une copie du document pour l'édition."
(sorry, this is french version, but "verrouillé" means locked).

Openkm can be downloaded on http://www.openkm.com/en/download-english.html
The version 6.3.1 community version.
The IT has installed the linux version on server.
On my PC, I have windows 7 OS.

Still, there is an already installed openkm demo server accessible to anyone
http://demo.openkm.com/OpenKM/login
I have the same issue with it, so I think you're better use it as it is faster ;-)

demo server config I inserted for server in LO file explorer
host: demo.openkm.com
user: user1
path: /OpenKM/webdav

for user1, password is pass0

Regards
Comment 11 Giuseppe Castagno (aka beppec56) 2015-11-02 17:16:36 UTC
(In reply to lnunes from comment #10)
> Hi Giuseppe.
> 
> Lo shows the lock message: "Le document XXX est verrouillé pour édition par: 
> XXXX 
> Ouvrez le document en lecture seule ou ouvrez une copie du document pour
> l'édition."
> (sorry, this is french version, but "verrouillé" means locked).

no problem, I speak French, though only  a little.

> 
> Openkm can be downloaded on http://www.openkm.com/en/download-english.html
> The version 6.3.1 community version.
> The IT has installed the linux version on server.
> On my PC, I have windows 7 OS.

thanks, I'll download a copy and install to have another WebDAV server to test.

> 
> Still, there is an already installed openkm demo server accessible to anyone
> http://demo.openkm.com/OpenKM/login
> I have the same issue with it, so I think you're better use it as it is
> faster ;-)

I tested with the OpenKM demo server and LO 5.1 current master:
1) loaded a new file there using LO (save as...)
2) checked that the file was there using the OpenKM desktop
3) reopened the file with LO, I didn't have errors

So I think the cause is something else.

Do you have a http:// connection or a https:// connection to your server?
In case of http:// probably some log can be registered with wireshark.
Comment 12 lnunes 2015-11-03 07:47:13 UTC
Hi.

Unfortunately, our server is only accessible from internal network.
Still, as I have the problem with the demo server and you do not, I guess this is an issue on my side linked to my configuration, not to the server itself. 
By the way, I run windows 7 professional version, SP1.

Also, are there some traces Ican gave you on LO that are logged, or need to be activated?

Regards


Note: If I create a file from LO, then save it in demo server with LO, it is ok. If I try to reopen it, I have the lock message.
Comment 13 lnunes 2015-11-03 08:18:20 UTC

I forgot, for windows 7 professional version, SP1,it is the 64 BITS version
Comment 14 Giuseppe Castagno (aka beppec56) 2015-11-03 14:34:26 UTC
lnunes:

I repeated the test in Windows 7, 32bit, the problem is reproducible.

Then it works in Linux but not in Windows.

Using a special crafted version of LO capable of logging the WebDAV internals, I accessed the test OpenKM server:

LO tries to lock the file but when it receives the lock command response from the server it finds the received answer garbled, so ignores it and tries again to lock the file generating the error you see.

From the net log I registered using Wireshark, I analyzed the raw result of the server response, at a quick glance I saw that OpenKM doesn't honor the lock timeout requested by LO: LO requests a timeout of 180 seconds, while OpenKM answers with a timeout set to infinite, instead of aswering with the same timeout.
This is probably something that should be set at the server side.

For now I still don't know what the real problem is, but I'll investigate further.
Comment 15 Alex Thurgood 2015-11-09 17:56:11 UTC
Tested on LO 5022, OSX 10.11.1

Uploaded ODT file via browser, then opened it via the native LO file picker from the webdav host, edited it, saved, closed, everything seems OK
Comment 16 Commit Notification 2015-11-10 12:34:55 UTC
Giuseppe Castagno committed a patch related to this issue.
It has been pushed to "master":

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

tdf#90249 fix lock timeout in neon for Windows platform.

It will be available in 5.1.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 17 Stephan Bergmann 2015-11-10 14:43:25 UTC
(In reply to Giuseppe Castagno (aka beppec56) from comment #14)
> LO tries to lock the file but when it receives the lock command response
> from the server it finds the received answer garbled, so ignores it and
> tries again to lock the file generating the error you see.

What is the content of the answer's TimeOut: line that LO finds garbled?

From the proposed patch at <https://gerrit.libreoffice.org/#/c/19867/2>, I assume that this issue (and thus any fix) is not really Windows-specific, but rather 32-bit--specific.
Comment 18 Giuseppe Castagno (aka beppec56) 2015-11-10 15:42:53 UTC
(In reply to Stephan Bergmann from comment #17)
> (In reply to Giuseppe Castagno (aka beppec56) from comment #14)
> > LO tries to lock the file but when it receives the lock command response
> > from the server it finds the received answer garbled, so ignores it and
> > tries again to lock the file generating the error you see.
> 
> What is the content of the answer's TimeOut: line that LO finds garbled?

'garbleb' was the first error returned from neon, at LO level, but then I enabled neon debug log and found the real problem.

My further comments are at gerrit <https://gerrit.libreoffice.org/#/c/19867/2>
Comment 19 Stephan Bergmann 2015-11-10 15:59:42 UTC
(In reply to Giuseppe Castagno (aka beppec56) from comment #18)
> 'garbleb' was the first error returned from neon, at LO level, but then I
> enabled neon debug log and found the real problem.
> 
> My further comments are at gerrit
> <https://gerrit.libreoffice.org/#/c/19867/2>

So what was the real problem exactly?  I cannot deduce that from the gerrit patch.

What I deduce from the gerrit patch is that the server presumably sends a

  TimeOut: Second-4294967295

reply, which the original code (under 32-bit long) would report as NE_TIMEOUT_INVALID (aka -2) and your patch would report as 4294967294 (aka LONG_MAX-1; is it even relevant for the fix that it is reported as 4294967294 instead of 4294967295?).

As such, I continue to suspect that this issue is not Windows-specific.
Comment 20 Stephan Bergmann 2015-11-10 16:02:30 UTC
(In reply to Stephan Bergmann from comment #19)
> What I deduce from the gerrit patch is that the server presumably sends a
> 
>   TimeOut: Second-4294967295
> 
> reply, which the original code (under 32-bit long) would report as
> NE_TIMEOUT_INVALID (aka -2) and your patch would report as 4294967294 (aka
> LONG_MAX-1; is it even relevant for the fix that it is reported as
> 4294967294 instead of 4294967295?).

Now I mixed up long and unsigned long in my deduction.  I defeat and claim I have no idea what the server presumably sent back.
Comment 21 Giuseppe Castagno (aka beppec56) 2015-11-10 16:49:22 UTC
(In reply to Stephan Bergmann from comment #20)
> (In reply to Stephan Bergmann from comment #19)
> > What I deduce from the gerrit patch is that the server presumably sends a
> > 
> >   TimeOut: Second-4294967295
> > 
> > reply, which the original code (under 32-bit long) would report as
> > NE_TIMEOUT_INVALID (aka -2) and your patch would report as 4294967294 (aka
> > LONG_MAX-1; is it even relevant for the fix that it is reported as
> > 4294967294 instead of 4294967295?).
> 
> Now I mixed up long and unsigned long in my deduction.  I defeat and claim I
> have no idea what the server presumably sent back.

The server sent:

TimeOut: Second-4294967295

in WebDAV legal value range from 0 to 4294967295, that is from 0 to ULONG_MAX.

My proposed patch set the value down to LONG_MAX-1 if the value is in the range
from LONG_MAX to ULONG_MAX. 
For pratical purpose LONG_MAX means a lock timeout of around 68 years, values above that seemed pointless to use.
I don't thing a file stays open for 68 years...

Though the proposed patch works, I'll work out a cleaner solution.
Comment 22 Giuseppe Castagno (aka beppec56) 2015-11-11 14:42:45 UTC
Checked on Linux, Kubuntu 14.04 with LO version 5.1.0.0-alpha1 32 bit, the bug is present.
Comment 23 Commit Notification 2015-11-12 16:46:19 UTC
Giuseppe Castagno committed a patch related to this issue.
It has been pushed to "master":

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

Related tdf#90249 A reinterpretation of the previous fix...

It will be available in 5.1.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 24 lnunes 2015-11-13 09:04:59 UTC
Hi 

I downloaded the daily version of yesterday evening (12/11/2015).
I confirm I can now open documents on webdav server. Great :-)
I performed some quick tests around file opening and lock and saw a missing lock.

Simple open/close : OK
* I open a document=> file lock is correctly set.
* I close the document => lock is released 

Open file and save with a new name : NOT OK
* I open a document1=> file lock is correctly set on document1.
* I save document1 as document2=> lock is released on document1 BUT lock is not set on document2
Comment 25 Stephan Bergmann 2015-11-13 09:44:11 UTC
(In reply to lnunes from comment #24)
> Open file and save with a new name : NOT OK
> * I open a document1=> file lock is correctly set on document1.
> * I save document1 as document2=> lock is released on document1 BUT lock is
> not set on document2

Please report that as a bug of its own.
Comment 26 lnunes 2015-11-13 10:07:32 UTC
ok. Done:
Bug 95792 - Lock missing when saving a file with a new name on a webdav server
Comment 27 Robinson Tryon (qubit) 2015-12-14 05:51:04 UTC Comment hidden (obsolete)