[ 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)