Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 11 Apr 2011 18:54:06 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1432780078.50059.1302548046760.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1662151784.7671.1300314149596.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-1760) problems with getFullPathName
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018506#comment-13018506 ] 

Daryn Sharp commented on HDFS-1760:
-----------------------------------

Ignore last comment.  Wrong jira.

> problems with getFullPathName
> -----------------------------
>
>                 Key: HDFS-1760
>                 URL: https://issues.apache.org/jira/browse/HDFS-1760
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.22.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>             Fix For: 0.23.0
>
>         Attachments: HDFS-1760.patch
>
>
> FSDirectory's getFullPathName method is flawed.  Given a list of inodes, it starts at index 1 instead of 0 (based on the assumption that inode[0] is always the root inode) and then builds the string with "/"+inode[i].  This means the empty string is returned for the root, or when requesting the full path of the parent dir for top level items.
> In addition, it's not guaranteed that the list of inodes starts with the root inode.  The inode lookup routine will only fill the inode array with the last n-many inodes of a path if the array is smaller than the path.  In these cases, getFullPathName will skip the first component of the relative path, and then assume the second component starts at the root.  ex. "a/b/c" becomes "/b/c".
> There are a few places in the code where the issue was hacked around by assuming that a 0-length path meant a hardcoded "/" instead of Path.SEPARATOR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira