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