[
https://issues.apache.org/jira/browse/HADOOP-14211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15939558#comment-15939558
]
Andrew Wang commented on HADOOP-14211:
--------------------------------------
Interesting find here Erik! I notice that both {{ChRootedFs}} and {{FilterFs}}
have this special, and probably both should be updated. Filtering a ViewFs is
also perhaps a more likely real-world usecase.
> ChRootedFs is too aggressive about enforcing "authorityNeeded"
> --------------------------------------------------------------
>
> 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
> Attachments: HADOOP-14211.000.patch
>
>
> 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]
