After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 532968 - DAV ignores path when mounting
DAV ignores path when mounting
Status: RESOLVED DUPLICATE of bug 561998
Product: gvfs
Classification: Core
Component: webdav backend
0.2.x
Other All
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-05-13 15:15 UTC by Ben Davis
Modified: 2010-02-16 12:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Ben Davis 2008-05-13 15:15:19 UTC
Please describe the problem:
Let's say I have a webdav server at  example.com/~me/webdav/.   The webdav root is the /~me/webdav path.  Anything outside of that path is standard html. 

When I type in "dav://example.com/~me/webdav/",   It prompts for the password, and then proceeds to do a PROPFIND on "/~me/webdav/~me/webdav", which for obvious reasons fails. 

I suspect the reason for this is that once you authenticate, the gvfs module creates the mount, at which point the url for accessing the dav folder is now: "dav://example.com", which translates to "exmaple.com/~me/webdav/".  So when we go to "dav://example.com/~me/webdav/"  it thinks we're asking for "dav://example.com/~me/webdav/~me/webdav".   

Steps to reproduce:
1. type in a webdav url where the webdav root is not the server root.
2. enter password (if asked for)

Actual results:
The resulting gvfs uri for the webdav becomes "dav://example.com"

The webdav client makes a PROPFIND request on the webdav path, followed by the webdav path again (eg: "PROPFIND /~me/webdav/~me/webdav").

Expected results:
The resulting gvfs uri should be the original path that was entered: "dav://example.com/~me/webdav", which would then result in a correct PROPFIND:
"PROPFIND /~me/webdav"

Does this happen every time?
yes

Other information:
Comment 1 Ben Davis 2008-05-13 15:27:21 UTC
I should add that this was done using nautilus.
Comment 2 Serge 2008-10-19 03:16:46 UTC
I have the exact same problem, but not only with dav, but also with ssh for example.

gvfs-mount ssh://server/homedir return with gvfs-mount -l 

Mount(0): sftp on server -> sftp://server/

gvfs-mount davs://server/dav return with gvfs-mount -l

Mount(0): WebDAV on server -> davs://server/
Comment 3 Mads Chr. Olesen 2009-02-02 08:25:59 UTC
Is this still a problem?
With Ubuntu 8.10 I can mount from "dav://example.com/dav/docs", where only /dav is the dav-enabled portion of the server. The mount succeeds.

However clicking the share in nautilus afterwards does in fact try to access the path /
Comment 4 Christian Kellner 2010-02-16 12:02:01 UTC
In GVfs mounts of remote servers work very much like "normal" UNIX mounts. So we take a remote server location and mount that as the share in GVfs. For this the DAV backend always tries to find the nearest-to-root path that is still a valid WebDAV enabled path and use that as mount specific (remote) root.

Within that process the original entry point was indeed "lost". This has -for DAV- changed since we now have support for default entry points to mounts. So this is basically a dup of bug #561998.

*** This bug has been marked as a duplicate of bug 561998 ***