[
https://issues.apache.org/jira/browse/HADOOP-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793827#action_12793827
]
Eli Collins commented on HADOOP-6427:
-------------------------------------
I think using a new syntax is preferable to using a partially qualified path.
Some rationale:
Using a partially qualified path:
* Using an existing scheme, eg hdfs:///foo is confusing since the "hdfs" is not
relevant since the client default file system might not be hdfs. And the file
scheme is always a partially qualified uri (ie file:///foo *should not* mean
use the default file system of the client, it means use the local file system).
Therefore file needs to be special cased, so it's inconsistent.
* Using a new scheme, eg default:///foo is a little odd since the scheme is
special-caed ("default" doesn't map to a class that extends
AbstractFileSystem). The behavior when a partially qualified path with
"default" scheme is made fully qualified would be quirky. Would it be an error?
Or ignore the authority?
* We could use an authority but no scheme, eg //default/, but that's bad
because it could be combined with another path (made qualified) in which case
"default" now has a different meaning (it's an authority).
Using new syntax:
* Use a prefix consisting of reserved URI characters that do not normalize
away, eg "%", ";" or "!". However these are valid Posix directory names so you
could not tell whether "%/foo" was a relative link or one that should be
resolved using the default file system of the file context.
* Use prefix that noramalizes away. Eg /// normalizes to / so ///foo normally
means /foo, and still would, except when used as a link target, where it would
now mean /foo resolved using the default file system of the client. There's no
ambiguity since users can still create an absolute link to foo using "/foo".
This would not change any existing semantics because symlinks are new and
symlink target resolution is the only place the new meaning would take effect.
Using a "///" prefix without a scheme is also uncommon. There are some details
to consider though, since /// normalizes away in the Path constructor we'd have
to add a flag to Path indicating that the Path was created with /// that would
be checked when getting the link target in FileContext. And that scheme:///foo
did not have the flag set. And we'd need to make sure the flag wasn't
propagated when creating a new fully qualified path.
What do people think of using a "///" prefix? We could also not shelve this
link type until users request it. It is useful, but probably the least common
link type.
> Add Path isQualified
> --------------------
>
> Key: HADOOP-6427
> URL: https://issues.apache.org/jira/browse/HADOOP-6427
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Eli Collins
> Assignee: Eli Collins
> Attachments: hadoop-6427-1.patch
>
>
> The Path class has a method to make a path qualified but not to query if the
> path is qualified. This is needed for HADOOP-64221. In addition this patch
> adds tests to TestPath that cover the file scheme. Note that "fully
> qualified" applies to domain names not URIs so this function and it tests
> also serve to define what we mean by a fully qualified path.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
