[
https://issues.apache.org/jira/browse/HDFS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146988#comment-14146988
]
Jing Zhao commented on HDFS-7104:
---------------------------------
Sorry I should mention this in my last comment:
{code}
E.g., for path /dir/.snapshot, an array of size 1 is returned, containing only
the inode of dir."
{code}
Here an array of size 2 is actually returned, since the root ("/") node is also
included :)
We can change it to sth. like "E.g., for path /dir/.snapshot with inodes
containing all the inodes involved in the path, an array of size 2 is returned,
containing both the root("/") and the inode of dir".
> 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
> Attachments: HDFS-7104-20140923-v1.patch,
> HDFS-7104-20140923-v3.patch, HDFS-7104-20140924-v1.patch,
> HDFS-7104-20140924-v2.patch
>
>
> 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)