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
Can't reproduce on Windows 8 with LibreOffice 4.4.1.2 accessing files on ownCloud server.
(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
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.
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
Hi Matus. Is there any news on your side for this subject? What do you suggest to do? THnaks a lot. Best regards.
(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.
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.
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.
(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.
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
(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.
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.
I forgot, for windows 7 professional version, SP1,it is the 64 BITS version
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.
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
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.
(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.
(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>
(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.
(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.
(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.
Checked on Linux, Kubuntu 14.04 with LO version 5.1.0.0-alpha1 32 bit, the bug is present.
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.
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
(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.
ok. Done: Bug 95792 - Lock missing when saving a file with a new name on a webdav server
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]