[
https://issues.apache.org/jira/browse/HADOOP-14211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Krogen updated HADOOP-14211:
---------------------------------
Description:
Right now {{ChRootedFs}} passes the following up to the {{AbstractFileSystem}}
superconstructor:
{code}
super(fs.getUri(), fs.getUri().getScheme(),
fs.getUri().getAuthority() != null, fs.getUriDefaultPort());
{code}
This passes a value of {{authorityNeeded==true}} for any {{fs}} which has an
authority, but this isn't necessarily the case - ViewFS itself is an example of
this. In fact you will encounter this issue if you try to nest one ViewFS
within another - I can't think of any reason why you would want to do that but
there's no reason why you shouldn't be able to and in general ViewFS is making
an assumption that it then proves invalid by its own behavior. The
{{authorityNeeded}} check isn't necessary in this case anyway; {{fs}} is
already an instantiated {{AbstractFileSystem}} which means it has already used
the same constructor with the value of {{authorityNeeded}} (and corresponding
validation) that it actually requires.
was:
Right now {{ChRootedFs}} passes the following up to the {{AbstractFileSystem}}
superconstructor:
{code}
super(fs.getUri(), fs.getUri().getScheme(),
fs.getUri().getAuthority() != null, fs.getUriDefaultPort());
{code}
This passes a value of {{authorityNeeded==true}} for any {{fs}} which has an
authority, but this isn't necessarily the case--ViewFS itself is an example of
this. In fact you will encounter this issue if you try to nest one ViewFS
within another--I can't think of any reason why you would want to do that but
there's no reason why you shouldn't be able to and in general ViewFS is making
an assumption that it then proves invalid by its own behavior. The
{{authorityNeeded}} check isn't necessary in this case anyway; {{fs}} is
already an instantiated {{AbstractFileSystem}} which means it has already used
the same constructor with the value of {{authorityNeeded}} (and corresponding
validation) that it actually requires.
> ChRootedFs is too aggressive about enforcing "needsAuthority"
> -------------------------------------------------------------
>
> Key: HADOOP-14211
> URL: https://issues.apache.org/jira/browse/HADOOP-14211
> Project: Hadoop Common
> Issue Type: Bug
> Components: viewfs
> Affects Versions: 2.6.0
> Reporter: Erik Krogen
> Assignee: Erik Krogen
>
> Right now {{ChRootedFs}} passes the following up to the
> {{AbstractFileSystem}} superconstructor:
> {code}
> super(fs.getUri(), fs.getUri().getScheme(),
> fs.getUri().getAuthority() != null, fs.getUriDefaultPort());
> {code}
> This passes a value of {{authorityNeeded==true}} for any {{fs}} which has an
> authority, but this isn't necessarily the case - ViewFS itself is an example
> of this. In fact you will encounter this issue if you try to nest one ViewFS
> within another - I can't think of any reason why you would want to do that
> but there's no reason why you shouldn't be able to and in general ViewFS is
> making an assumption that it then proves invalid by its own behavior. The
> {{authorityNeeded}} check isn't necessary in this case anyway; {{fs}} is
> already an instantiated {{AbstractFileSystem}} which means it has already
> used the same constructor with the value of {{authorityNeeded}} (and
> corresponding validation) that it actually requires.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
