Bug 949906

Summary: Colons in automatically created names by gvfs-fuse cause problems
Product: [Fedora] Fedora Reporter: fedora
Component: gvfsAssignee: Tomáš Bžatek <tbzatek>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: alexl, bnocera, tbzatek, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-09 09:19:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description fedora 2013-04-09 09:13:29 UTC 
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

  smb-share:server=myserver,share=myshare

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.

  https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075868

Version-Release number of selected component (if applicable):
gvfs-fuse-1.14.2-3.fc18.x86_64

How reproducible:
Always.

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>
  
Actual results:
Failure with error from above.

Expected results:
Cloned git repository.

Additional info:
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".
Comment 1 Tomáš Bžatek 2013-04-09 09:19:19 UTC 
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.
Comment 2 fedora 2013-04-09 09:32:18 UTC 
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.
Comment 3 fedora 2013-04-09 09:39:01 UTC 
By the way it would fix very easily, for example by using an underscore or minus character instead of the colon.
Comment 4 Tomáš Bžatek 2013-04-09 09:43:40 UTC 
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.
Comment 5 Tomáš Bžatek 2013-04-09 09:45:55 UTC 
(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.
Comment 6 fedora 2013-04-09 12:02:45 UTC 
(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.