[
https://issues.apache.org/jira/browse/HADOOP-14211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Wang updated HADOOP-14211:
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0.0-alpha3
2.9.0
Status: Resolved (was: Patch Available)
Thanks Erik, committed to trunk and branch-2.
Have you checked if FilterFileSystem and ViewFileSystem suffer from a similar
problem? Most apps are more comfortable with the FileSystem APIs. I don't know
anything that uses FileContext besides YARN and MR2.
> FilterFs and ChRootedFs are 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
> Fix For: 2.9.0, 3.0.0-alpha3
>
> Attachments: HADOOP-14211.000.patch, HADOOP-14211.001.patch
>
>
> Right now {{FilterFs}} and {{ChRootedFs}} pass 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 is an example of
> this. You will encounter this issue if you try to filter a ViewFS, or nest
> one ViewFS within another. 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]
