[
https://issues.apache.org/jira/browse/HADOOP-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756945#comment-13756945
]
Colin Patrick McCabe commented on HADOOP-9929:
----------------------------------------------
This is a good catch, Jason.
The solution to this might be a bit tricky.
If we're listing a single path (like /a/b/c), we definitely want to throw
AccessControlException if we can't get to c.
If we're listing a glob like /a/*/c, I'm not sure if we want to abort the whole
glob (by throwing an exception), just because one path was not accessible to
us. Perhaps we should just return the things we can get to? For what it's
worth, the old behavior in branch-1 is to abort the whole glob, I believe.
Another aspect is that exceptions such as StandbyException, etc. should
*always* just propagate to the top level. Basically any IOException that we
don't specifically catch (like permission denied, etc.) we should propagate to
the top level, aborting the globStatus.
> Insufficient permissions for a path reported as file not found
> --------------------------------------------------------------
>
> Key: HADOOP-9929
> URL: https://issues.apache.org/jira/browse/HADOOP-9929
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 2.1.0-beta, 2.0.4-alpha
> Reporter: Jason Lowe
>
> Using "hadoop fs -ls" to list a path where the permissions of a parent
> directory are insufficient ends up reporting "no such file or directory" on
> the full path rather than reporting the permission issue. For example:
> {noformat}
> $ hadoop fs -ls /user/abc/tests/data
> ls: `/user/abc/tests/data': No such file or directory
> $ hadoop fs -ls /user/abc
> ls: Permission denied: user=somebody, access=READ_EXECUTE,
> inode="/user/abc":abc:hdfs:drwx------
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
