Problem description: If you open a file on a webdav server (https://....) using windows explorer, LO opens the file without asking your webdav credentials however LO sets a webdav lock. You try then to save the file more than once, LO seems to try to save the file normally using the network share ie Y:\\... This lead to a "general i/o error", because the webdav server refuses to write on a locked file Steps to reproduce: 1. Mount a webdav network share using the windows explorer 2. Browse and double click on a test file (test.odt) 3. Modify the file and click save Current behavior: You will get "Error saving the document "XXX": Access to \\subdomain.domain.com@SSL\xxxxx\webdav\test.odt was denied." then "General input/output error" Expected behavior: if a document is opened on a webdav share, LO should save it using the webdav protocol and therefore asking you the credential before saving. when trying to do 'save as', it should also try to use webdav Hint: perhaps that LO is misled by Windows that transform the https://subdomain.domain.com in \\subdomain.domain.com@SSL Final remark: this seems to be a longstanding issue and very annoying. In some case could avoid corporation to migrate from Office to LibreOffice when using a dav server ___________ similar references: http://forum.openoffice.org/en/forum/viewtopic.php?f=17&t=35255 http://lists.freedesktop.org/archives/libreoffice-bugs/2011-May/011306.html https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1069757 Operating System: Windows 7 Version: 4.0.1.2 release
Hello Christopher, *, I can partly confirm your bug with Konqueror Version 4.8.4 under Debian AMD64 and using my box.net account: If I use "konqueror webdav://box.net/dav", I have to enter my user name and password, but am not able to save any changes to a test file, which I copied via Konqueror to my box.net site ... :( LO Version 4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539) with installed Germanophone lang- as well as helppack can open this file, I can edit it, but LO only seems to save it. When I reopen it again, no changes are there ... :( I did some further testing (and here comes the reason, why I added the "NEEDINFO" tag to this bug ... ;) ) and found out, if I press <CTRG>+<O> to open a file, enter http://box.net/dav, I am able to open my test file (after entering user name and password), edit and save it afterwards - and the changes stay there, when I reopen it again :) Would you be so kind to test it that way (either use my shortcut, use File - Open or click on the icon), enter the path to your webdav file as URL (or maybe you could try to click to your mounted webdav share, where you can choose the test file)? Does it work that way? Sorry for the inconvenience and have a nice day Thomas.
(In reply to comment #1) > Would you be so kind to test it that way (either use my shortcut, use File - > Open or click on the icon), enter the path to your webdav file as URL (or > maybe you could try to click to your mounted webdav share, where you can > choose the test file)? Does it work that way? Waiting for reply from OP, Status -> NEEDINFO (Christopher: Please change the status back to 'UNCONFIRMED' after you've answered the questions :-)
First of all happy new year and thanks to the LO community for this great software. We have done new tests (including the one suggested opening with https://) with the following environment ; LO 4.1.3.2 release connecting a Webdav server (Alfresco 4.0.d and 4.2.d) And I have to say that this bug does not occur anymore with LO 4.1.3.2 / Alfresco 4.2.d and we can't reproduce it with Alfresco 4.0.d Therefore with believe that LO changed the way webdav is implemented and now everything works perfectly.
(In reply to comment #3) > And I have to say that this bug does not occur anymore with LO 4.1.3.2 / > Alfresco 4.2.d and we can't reproduce it with Alfresco 4.0.d > > Therefore with believe that LO changed the way webdav is implemented and now > everything works perfectly. Sounds good -- resolving as 'WORKSFORME'. Thackert - If you can still repro this problem in a modern build, please change status back to UNCONFIRMED (or open a new bug, if you think you're running into a slightly different issue!) Thanks!