[
https://issues.apache.org/jira/browse/HDFS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhe Zhang updated HDFS-7104:
----------------------------
Description:
inodes is initialized with the number of patch components. After resolve, it
contains both non-null and null elements (introduced by dot-snapshot dirs).
When getINodes is called, an array is returned excluding all non elements,
which is the correct behavior. Meanwhile, the inodes array is trimmed too,
which shouldn't be done by a getter.
Because of the above, the behavior of getINodesInPath depends on whether
getINodes has been called, which is not correct.
The name of getLastINodeInPath is confusing – it actually returns the last
non-null inode in the path. Also, shouldn't the return type be a single INode?
> Fix and clarify INodeInPath getter functions
> --------------------------------------------
>
> Key: HDFS-7104
> URL: https://issues.apache.org/jira/browse/HDFS-7104
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Priority: Minor
>
> inodes is initialized with the number of patch components. After resolve, it
> contains both non-null and null elements (introduced by dot-snapshot dirs).
> When getINodes is called, an array is returned excluding all non elements,
> which is the correct behavior. Meanwhile, the inodes array is trimmed too,
> which shouldn't be done by a getter.
> Because of the above, the behavior of getINodesInPath depends on whether
> getINodes has been called, which is not correct.
> The name of getLastINodeInPath is confusing – it actually returns the last
> non-null inode in the path. Also, shouldn't the return type be a single INode?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
