[ https://issues.apache.org/jira/browse/HADOOP-14211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erik Krogen updated HADOOP-14211: --------------------------------- Summary: ChRootedFs is too aggressive about enforcing "authorityNeeded" (was: ChRootedFs is too aggressive about enforcing "needsAuthority") > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org