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 590862 - Bad mount prefix stripping in g_daemon_file_get_path()
Bad mount prefix stripping in g_daemon_file_get_path()
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: client module
git master
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on: 590730
Blocks:
 
 
Reported: 2009-08-05 14:58 UTC by Tomas Bzatek
Modified: 2009-08-18 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gvfs-1.3.4-dont-strip-mount-prefix-for-local-paths.patch (1.33 KB, patch)
2009-08-05 15:04 UTC, Tomas Bzatek
rejected Details | Review

Description Tomas Bzatek 2009-08-05 14:58:12 UTC
Problem: calling g_file_get_path () for complex URIs like 'dav://server/gallery/w/TestAlbum' will return malformed path '/home/user/.gvfs/WebDAV on server/TestAlbum', i.e. with the middle part '/gallery/w' stripped.

This results in inability to directly open complex URIs from the Gnome Run dialog, nautilus-connect-server and any file from Nautilus (i.e. the passed URI to associated applications is not correct).
Comment 1 Tomas Bzatek 2009-08-05 15:04:31 UTC
Created attachment 139946 [details] [review]
gvfs-1.3.4-dont-strip-mount-prefix-for-local-paths.patch

Proposed patch, always return full path with prefix.

Now, I don't know GIO and gvfs internals that much to be 100% sure with this change and it's quite invasive, so I would like to have your look at it first. From my testing it works fine, but the GIO world is too broad for one man to know all consequences.
Comment 2 Tomas Bzatek 2009-08-07 16:15:37 UTC
More complex patch is needed to fix fuse daemon path issues and mount duplication due to incorrect mount_spec setting. Somewhat related to bug 590730.
Comment 3 Alexander Larsson 2009-08-18 07:57:15 UTC
That doesn't look right. The .gvfs directory ("~/.gvfs/WebDAV on Server" in this case) is supposed to point into the actual mount, and that means "inside" the mount prefix.

Mount prefixes are a bit tricky. The easiest way to understand them is to think about the NFS case. In NFS, a mount is identifed by a server ip + the location on the server of the exported filesystem. When encoded as a URI, we save the last thing as a prefix of the path. So, if you mount /mnt/foobar on server.com and access the file called subdir/the_file.txt in that mount the URI would be: nfs://server.c/mnt/foobar/subdir/the_file.txt

However, this is just the way the URI looks. Internally we store things as a mountspec (a unique identifier for the mount) plus a path relative to the mount. For the example above the mount spec would be: 
  host="server.com", mount_prefix="/mnt/foobar"
And the path would be "subdir/the_file.txt".

If the display name of such an example mount is "NFS on server.com" I would expect to access the file at "~/.gvfs/NFS on server.com/subdir/the_file.txt", not on "~/.gvfs/NFS on server.com/mnt/foobar/subdir/the_file.txt"

Dav uses mount prefix similarly to NFS, since there is no guarantee that the DAV share goes all the way up to the root of the webserver. So, when mounting we stat-walk up finding the "root".

Now, its clearly a bug that we can't access the file however. But the bug seems to be that we're not correctly adding the mount_prefix to the uri when converting from the fuse path, or something like that.
Comment 4 Tomas Bzatek 2009-08-18 13:57:03 UTC
Committed slightly different patch to master as 13ae4361636faf02d34c703986a470a6d2bae80c.

Thanks Alex for the help.