Bug 116420 - Error when I try to open an Document in a Sharepoint WebDAV directory (# is not allowed in a filename)
Summary: Error when I try to open an Document in a Sharepoint WebDAV directory (# is n...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.2.1 release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0 target:6.0.5
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks: WebDAV
  Show dependency treegraph
 
Reported: 2018-03-15 17:36 UTC by mayer-freiberg
Modified: 2018-09-11 13:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Error when trying to open a file from the browser (160.33 KB, image/png)
2018-06-26 16:40 UTC, Gabor Kelemen
Details
Opening a file from the same SP in the File Explorer (133.42 KB, image/png)
2018-06-26 16:42 UTC, Gabor Kelemen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mayer-freiberg 2018-03-15 17:36:22 UTC
Description:
Hello, since LO 6 I can't open a Document in a WebDAV directory on a sharepoint Server.
When I try to to this, I get an error Message: (in german) "Die Sperrdatei konnte für den Exklusivzugriff durch LibreOffice nicht erstellt werden, da die Berechtigung nicht ausreicht, um eine Sperrdatei am Dateiort zu erstellen, oder nicht ausreichend Speicherplatz zur Verfügung steht."

The reason seems to be, that LO tries to write the lockfile with ending .odt#. But # is not allowed in a filename on the Sharepoint Server.

Until LO5 this was no problem, the problem comes with LO6. It seems that LO5 opens the Document although it can't write the lock life. LO6 stops wirh the erroe message.





Steps to Reproduce:
1.Connect to a WebDAV share 
2.Open an odt file with LO6
3.

Actual Results:  
Error Message appears: "Die Sperrdatei konnte für den Exklusivzugriff durch LibreOffice nicht erstellt werden, da die Berechtigung nicht ausreicht, um eine Sperrdatei am Dateiort zu erstellen, oder nicht ausreichend Speicherplatz zur Verfügung steht."

That means that the lock file could not be created because of missing rights.

Expected Results:
Open the document


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Buovjaga 2018-03-16 14:11:54 UTC
Gábor: can you confirm this?
Comment 2 Gabor Kelemen 2018-03-16 18:37:22 UTC
Will take a look next week.
Comment 3 Gabor Kelemen 2018-03-20 17:00:47 UTC
Okay, so we don't have WebDAV access, but let's try something else:

Starting with a filename "LO-watermark-135deg.docx", opening it in Word 2013 results in a lockfile named "~$-watermark-135deg.docx".
I cannot copy this lockfile to our SP 2010 instance in Explorer on Win 8.1, since the ~ (at the beginning of the name) is not allowed.

Opening it in LO 5.4.5 results in a lockfile named ".~lock.LO-watermark-135deg.docx#" 
This is problematic because:
- dot is not allowed at the beginning of the file name
- tilde is not allowed at all
- hashmark is not allowed at all
in file names stored on SP.

Also see 
https://support.microsoft.com/en-us/help/905231/information-about-the-characters-that-you-cannot-use-in-site-names-fol

"You cannot use the following characters anywhere in a file name:

    Tilde
    Number sign
    Percent
    Ampersand
    Asterisk
    Braces
    Backslash
    Colon
    Angle brackets
    Question mark
    Slash
    Pipe
    Quotation mark"

and

"You cannot start a file name by using the period character."

I guess it's enough to set this to NEW.

Also, when opening files from this share by double clicking on them in Explorer, neither MSO nor LO tries to create lock files.
Comment 4 mayer-freiberg 2018-03-21 07:17:45 UTC
Hello,

I gan give you access to a webdav folder to test - but i won't write the account informations here.

I can open end edit documents from the webdav folder by doubleclick:

- with LO 5.4.5.1
- with Open Offoce 4.1.5
- with MS Word 2010 and 2016
- with notepad

None of them seems to create a lockfile in the webdav folder.

The problem is only with LO 6.x. Maybe the problem ist what LO 6
does, when it cannot create the lockfile. LO5 opens the document, LO6 not.

Greatings Andreas
Comment 5 Mike Kaganski 2018-04-17 22:08:20 UTC
https://gerrit.libreoffice.org/53070
Comment 6 Aron Budea 2018-04-17 23:33:00 UTC
(In reply to mayer-freiberg from comment #4)
> I can open end edit documents from the webdav folder by doubleclick:
> 
> - with LO 5.4.5.1
> - with Open Offoce 4.1.5

Most likely a regression from the fixes to bug 106942.
Comment 7 Commit Notification 2018-04-18 07:09:20 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#116420: Windows: Test if a filepath redirects to a WebDAV resource

It will be available in 6.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 8 Juergen Funk (CIB) 2018-04-20 05:44:11 UTC
The patch is more of a hack, why is the problem avoided and not solved correctly (use characters valid for all platforms), so our lock machanism doesn't work anymore in this case.
Which I think the problem is also in this tdf#115747, and this is not under windows.
Comment 9 Mike Kaganski 2018-04-20 06:05:21 UTC
(In reply to Juergen Funk (CIB) from comment #8)

Well - yes, it's more of a hack, but not because we should use universally valid characters: imo, ideally we shouldn't use lockfiles on WebDAV, and should use its own locking instead. Creation of lockfiles on such resources adds to commit history on server, especially where those commits are automatic, and may sum up quickly.
Comment 10 Mike Kaganski 2018-04-20 06:07:51 UTC
... Forgot to add: my idea would be to move this check higher, before the creation itself; but I'm unsure of preformance implications of the code, that's why I now only call it in a catch block.
Comment 11 Juergen Funk (CIB) 2018-04-23 05:04:28 UTC
Hi Mike,

the other question, wy only for the win-version?
Comment 12 Mike Kaganski 2018-04-23 05:27:49 UTC
(In reply to Juergen Funk (CIB) from comment #11)
> the other question, wy only for the win-version?

:) well - I don't know if there is a similar non-Windows redirector technology. Of course, if there is one, then we should also do that there.
Comment 13 Commit Notification 2018-05-30 12:24:28 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=37a462747af2abe6bde371607a965011534cab81&h=libreoffice-6-0

tdf#116420: Windows: Test if a filepath redirects to a WebDAV resource

It will be available in 6.0.5.

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 14 Gabor Kelemen 2018-06-26 16:40:40 UTC
Created attachment 143138 [details]
Error when trying to open a file from the browser

I'm trying use the 6.0.5 version with our SharePoint 2010 server, but no luck so far. 
The same error happens when trying to open a file for editing from the Web UI.
(maybe this use case was not supposed to be fixed by this?)

Version: 6.0.5.2
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 1; OS: Windows 6.1; UI render: default; 
Locale: en-US (hu_HU); Calc: group
Comment 15 Gabor Kelemen 2018-06-26 16:42:24 UTC
Created attachment 143139 [details]
Opening a file from the same SP in the File Explorer

Also, when trying to open a file from a WebDav-attached share, that fails too.
Comment 16 Gabor Kelemen 2018-06-26 17:14:12 UTC
However, file opening both from Explorer and IE works fine in current master:

Version: 6.2.0.0.alpha0+
Build ID: 757d9e43315755869af30e79c0457fd529cb050a
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-26_02:27:27
Locale: hu-HU (hu_HU); Calc: group threaded

I'm puzzled :(.
Comment 17 Gabor Kelemen 2018-06-27 07:32:52 UTC
Just tried with 6.1 beta2, and that works fine as well.

Is is possible that this fix is also needed: 
https://cgit.freedesktop.org/libreoffice/core/commit/sfx2/source/doc/docfile.cxx?id=2a7057250c8f73fdfb4c65a7525d17e9770459df

Also, I see some other file-locking related changes in the log of 
https://cgit.freedesktop.org/libreoffice/core/log/sfx2/source/doc/docfile.cxx
that may or may not be relevant here as well.

@Mike, does this ring a bell?
Comment 18 Mike Kaganski 2018-06-27 08:52:37 UTC
(In reply to Gabor Kelemen from comment #17)
> Is is possible that this fix is also needed: 
> https://cgit.freedesktop.org/libreoffice/core/commit/sfx2/source/doc/docfile.
> cxx?id=2a7057250c8f73fdfb4c65a7525d17e9770459df

Well - not this one; but possibly some others... there were quite a number of changes around this. Can't invest into this atm; also, the changes around locking are generally quite intrusive, so I usually hesitate backporting them.
Comment 19 Aron Budea 2018-09-11 13:00:04 UTC
Let's consider this fixed, thanks, Mike! Other cases, or a possible "proper" fix (eg. as outlined in comment 10) can be traced in their own bug reports.