hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Krogen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HADOOP-14211) FilterFs and ChRootedFs are too aggressive about enforcing "authorityNeeded"
Date Fri, 24 Mar 2017 17:05:41 GMT

     [ 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 {{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.

  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.


> 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
>         Attachments: HADOOP-14211.000.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: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message