[jira] Commented: (HDFS-961) dfs_readdir incorrectly parses paths

["Eli Collins (JIRA)" <ji...@apache.org>]

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

Eli Collins commented on HDFS-961:
----------------------------------

Would be great to check this into branch-20, see this problem come up on the lists frequently.

> dfs_readdir incorrectly parses paths
> ------------------------------------
>
>                 Key: HDFS-961
>                 URL: https://issues.apache.org/jira/browse/HDFS-961
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: contrib/fuse-dfs
>    Affects Versions: 0.20.1, 0.20.2, 0.21.0
>            Reporter: Eli Collins
>            Assignee: Eli Collins
>             Fix For: 0.21.0
>
>         Attachments: hdfs-961-1.patch, hdfs-961-2.patch
>
>
> fuse-dfs dfs_readdir assumes that DistributedFileSystem#listStatus returns Paths with the same scheme/authority as the dfs.name.dir used to connect. If NameNode.DEFAULT_PORT port is used listStatus returns Paths that have authorities without the port (see HDFS-960), which breaks the following code. 
> {code}
> // hack city: todo fix the below to something nicer and more maintainable but
> // with good performance
> // strip off the path but be careful if the path is solely '/'
> // NOTE - this API started returning filenames as full dfs uris
> const char *const str = info[i].mName + dfs->dfs_uri_len + path_len + ((path_len == 1 && *path == '/') ? 0 : 1);
> {code}
> Let's make the path parsing here more robust. listStatus returns normalized paths so we can find the start of the path by searching for the 3rd slash. A more long term solution is to have hdfsFileInfo maintain a path object or at least pointers to the relevant URI components.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.