[
https://issues.apache.org/jira/browse/HADOOP-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789462#comment-13789462
]
Sanjay Radia commented on HADOOP-9780:
--------------------------------------
The description and comments seem to be talking of two different things.
# the description says that following the symlink breaks compatibility. (I
disagree - symlinks are suppose to be transparent for the most part).
# the comments discuss two things - RPC costs and client-context-sensitivity.
** If the symlink is /relative with no scheme then the NN has the option of
resolving it to reduce the rpcs. We should do this. This was discussed during
the symlink design and was marked as future optimization - we should have filed
a jira for that at that time.
** if the symlink is fully-qualified with a scheme then it needs to be
resolved on client side; an optimization can be done by the NN if the scheme
and authority matches that of the NN. The NN cannot resolve a fiully qualified
name that does not match its own scheme and authority due to security.
There is no client context-sensitivity unless different clients are using
inconsistent DNS servers.
> 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)
