I've tried to setup a secure webdav connection to a Zimbra file briefcase (shared folder) with Gigolo. Its location is, by general consensus, something like "https://ZIMBRASERVER/dav/USERNAME/Briefcase". To cut down any possible problem, I've avoided using folders and usernames including "@" characters. At first, I've had no success. Setting up a Secure Webdav connection in Gigolo prompts for the following items: - server - path - port - folder - username No problem about server (it's the server for webmail access name), port and username (the mail user name). But path and folder are acting in a wierd name. In order to be saved, "path" has not to begin with /, otherwise it is discarded (?). "folder" is retained, but it seems to be completely ignored when trying to open the connection. Actually, there's no need to have two distinct fields; a single "folder" should be enough (Webdav's folders are like regular HTTP folders). If you realize all of this (and it's not easy to figure it out: "path" should be the complete path without leading "/", "folder" doesn't matter), you luckily manage to connect to the share; however, trying to double click on the connection icon results in a 'Cannot open "davs://USERNAME@SERVER/". Not a WebDAV enabled share' (sic) error. Path has been forgot again. I've also tried to create a "custom location" bookmark with a "davs://USERNAME@SERVER/dav/USERNAME/Briefcase" URI. Gigolo recognizes it as a regular WebDav share and reformat it as such, but in doing so breaks things, by completely losing the path specification. I suggest to use a single "path" value for "dav:" and "davs:" bookmarks, and make sure it is saved and used when creating the bookmark, connecting to resource, and open it in main Gigolo window after connection. $uname -srvmio Linux 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 GNU/Linux $gigolo -V gigolo 0.4.1 Copyright (c) 2008-2010 Enrico Tröger <enrico@xfce.org>
Thanks for the detailed bug report. Actually, WebDav URI handling was broken, or better, not completely implemented and this is why mounting by entering a WebDav URi manually didn't work. This should be fixed in GIT. About path and folder: there is reason why these are two separate fields: path is the part appended to the generated URI for connecting to the WebDav resource. folder is not used at all for connecting, it is only used when opening an established WebDav connecting in the file browser. Then the folder part is appended to the path (this is most useful for SFTP connections which are usually homed at / on the remote side but often you want to open /home/<username> in the file browser. It's some kind of shortcut and may be useful for WebDav as well). To make this a little clearer, added a tooltip to the folder field in the bookmark create dialog in GIT. The bug when entering a path in the dialog with a leading slash was also fixed in GIT. Now, things should be a bit better regarding WebDav resource connections. Could you test current GIT master to verify?
I've tried the GIT version; it's much better but IMO there's still something to iron. What works: - Saving of path with leading "/"; - Tooltip about folder setting - Creating bookmark via "custom location" and "davs://user@SERVER/PATH" What still doesn't work: - Opening (double-clicking) a DAVS bookmark on main window after mounting fails, it seems to be missing "path" part - only server and folder are used. What appears in tooltip and "copy URI" is correct, however. I still don't get the point for having a separate "path" and a "folder" setting. WebDAV access is done via HTTP requests, so it should be inherently stateless: permissions for entering some folder is not affected by the one you've accessed initially. When you open a connection to "/some/deep/path", it is completely exposed when browsing; you can go up to parent folder (/some/deep and /some) without issues, and go down to other paths too. So, I think "Folder" setting could be dropped at all.
> What still doesn't work: > - Opening (double-clicking) a DAVS bookmark on main window after mounting > fails, it seems to be missing "path" part - only server and folder are used. Could you go into detail about what doesn't work exactly? Please start Gigolo from the command line with --verbose and post its output after you double-clicked the connection. > I still don't get the point for having a separate "path" and a "folder" > setting. WebDAV access is done via HTTP requests, so it should be inherently The WebDAV entry point and some arbitary folder after it are two different things. If I mount my OwnCloud WebDAV share for example, the mount URI looks like: davs://enrico@server.tld/owncloud/files/webdav.php In Gigolo, this is server.tld is the server, owncloud/files/webdav.php is the path. After that, any sub folders are to be appended by the folder setting. However, using the folder setting directly in the URI to be mounted by GVfs would work, e.g. davs://enrico@server.tld/owncloud/files/webdav.php/Documents/LaTeX would be mounted by GVfs as davs://enrico@server.tld/owncloud/files/webdav.php as it detects the entry point and strips the folder part and then the folder Documents/LaTeX is lost. This is why there are two separate settings for path and folder in Gigolo, in order to enable Gigolo to "reconstruct" the URI after it is mounted to be passed to a file manager. If you don't need it, simply leave folder empty.