hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9780) Filesystem and FileContext methods that follow symlinks should return unresolved paths
Date Tue, 08 Oct 2013 16:46:42 GMT

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

Chris Nauroth commented on HADOOP-9780:
---------------------------------------

bq. If the scheme of the absolute symlink is viewfs://, it's a cross-filesystem symlink, and
we throw it back to the client. If it's hdfs://, it's ours and we handle it.

Is the proposal to add scheme-checking logic on the namenode side?  The challenge here is
that the client can freely remap schemes to filesystems, so the hdfs scheme isn't necessarily
{{org.apache.hadoop.fs.Hdfs}}, and the viewfs scheme isn't necessarily {{org.apache.hadoop.fs.viewfs.ViewFs}}.
 Perhaps it's uncommon for clients to remap schemes, but it's possible.

It seems that a cross-filesystem symlink target stored with a specific scheme in HDFS does
not have a single absolute meaning.  Instead, the meaning is context-sensitive depending on
the client.  Client A may resolve it differently from client B.  Perhaps this could be handled
by passing some kind of "link resolution context" in the RPCs, which would represent the client's
view of the schemes?

> Filesystem and FileContext methods that follow symlinks should return unresolved paths
> --------------------------------------------------------------------------------------
>
>                 Key: HADOOP-9780
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9780
>             Project: Hadoop Common
>          Issue Type: Sub-task
>            Reporter: Colin Patrick McCabe
>            Priority: Minor
>
> Currently, when you follow a symlink, you get back the resolved path, with all symlinks
removed.  For compatibility reasons, we might want to have the returned path be an unresolved
path.
> Example: if you have:
> {code}
> /a -> b
> /b
> /b/c
> {code}
> {{getFileStatus("/a/c")}} will return a {{FileStatus}} object with a {{Path}} of {{"/b/c"}}.
> If we returned the unresolved path, that would be {{"/a/c"}}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message