Bug 949906 - Colons in automatically created names by gvfs-fuse cause problems
Summary: Colons in automatically created names by gvfs-fuse cause problems
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gvfs
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-09 09:13 UTC by fedora
Modified: 2015-03-03 23:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-09 09:19:19 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1075868 0 None None None Never

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.


Note You need to log in before you can comment on or make changes to this bug.