Description of problem:
The new naming scheme of gvfs-fuse creates directory names of mounted volumes under /run/user/<uid>/gvfs that contain colons, for example
Using this path fails in several applications. For example if you want to clone a git repository located on this volume, you get an error:
ssh: Could not resolve hostname /run/user/<uid>/gvfs/smb-share: Name or service not known
I would assume the same will happen when using CVS or SVN.
While looking for this problem, I also found the following bug report for Ubuntu that states that this colon also causes problems when using Wine apps.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use nautilus to mount a windows share with a git repository on it
2. Clone the git repository to your local directory by using the automatic file name (correctly escaped), e.g.
git clone /run/user/<uid>/gvfs/smb-share\:server\=myserver\,share\=myshare/<git-repo>
Failure with error from above.
Cloned git repository.
Because of the colon in the automatic file name, the beginning of the path is interpreted as a server name by the git command.
I believe such automatic names as created by gvfs-fuse should avoid special characters that are used in a different context elsewhere. The colon will definitely be a problem as it is a separator in URIs (Server) and Windows file names (drive character). The comma might be a problem in environments where a list of paths is expected. I'm not sure about the equal sign.
This used to work fine before Fedora 17 when the naming scheme was "volume on server".
This should be fixed in those applications instead, it's a nice demonstration how broken they are. Please file respective bugreports for all affected components.
Sorry, but how can I address *all* applications that allow an URI? Every application that allows an URI with "server://path" in addition to a pure file name will fail! I don't think all those applications are broken, I think gvfs-fuse is broken because it breaks all those applications that existed before this new naming scheme! URI is a standard!!! See https://en.wikipedia.org/wiki/Uniform_resource_identifier.
By the way it would fix very easily, for example by using an underscore or minus character instead of the colon.
Sooner or later somebody else will face the same issue, fixing it in gvfs is pointless, this is a larger issue. Anybody can create a path like this, even use it for mountpoints having homedirs etc. Colons and commas are allowed file name/path characters in POSIX world.
Applications should detect the first path separator (a slash) indicating local absolute path. Alternatively you may want to pass local file scheme prefix "file://" that the applications expecting valid URI would interpret just fine (and you may want to URI-encode some characters).
Btw. not sure how g_file_new_for_commandline_arg () behaves, it's worth testing it. Not on gvfsd-fuse generated paths since it's transparently translated to original URI.
(In reply to comment #3)
> By the way it would fix very easily, for example by using an underscore or
> minus character instead of the colon.
Yes, it's a oneliner, but you made a good test case, need to fix the root cause, not a consequence.
(In reply to comment #4)
> Alternatively you may want to pass local file scheme
> prefix "file://" that the applications expecting valid URI would interpret
> just fine (and you may want to URI-encode some characters).
Good idea. git seems to run then.
Nonetheless why make it unnecessary difficult when changing a single character ':' -> '_' could make life so much simpler? In 99% there would be no need for the prefix "file://". I would say many people have stumbled or will stumble over this. Why provoke problems that needn't be there in the first place? Sometimes it is not wise to do something just because you *can* do it. It is never wise to use ':' in a file name even if you are allowed to.