[
https://issues.apache.org/jira/browse/HDFS-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786311#comment-13786311
]
Daryn Sharp commented on HDFS-5294:
-----------------------------------
It's a dup in concept, but addressing the issue described will require a
specific change to {{DistributedFileSystem}}'s {{getFileLinkStatus}} and
{{getLinkTarget}} so I think it should stay open in addition to the common jira.
bq. [...] t will also affect getFileStatus, listStatus, getLocatedFileStatus,
resolvePath, listCorruptFileBlocks, globStatus, createSnapshot, etc. [...] I
really don't think we should do this unless we also do symlink resolution
server-side to avoid doing N symlink resolution RPCs every time we use a path
with N symlinks in it.
I think there's some misunderstanding. The issue of whether the client is able
to obtain the exact symlink target is orthogonal from whether the other methods
return a {{FileStatus}} with a (un)qualified path.
> DistributedFileSystem#getFileLinkStatus should not fully qualify the link
> target
> --------------------------------------------------------------------------------
>
> Key: HDFS-5294
> URL: https://issues.apache.org/jira/browse/HDFS-5294
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs-client
> Affects Versions: 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
>
> The NN returns a {{FileStatus}} containing the exact link target as specified
> by the user at creation. However,
> {{DistributedFileSystem#getFileLinkStatus}} explicit overwrites the target
> with the fully scheme qualified path lookup. This causes multiple issues
> such as:
> # Prevents clients from discerning if the target is relative or absolute
> # Mangles a target that is not intended to be a path
> # Causes incorrect resolution with multi-layered filesystems - ie. the link
> should be resolved relative to a higher level fs (ie. viewfs, chroot,
> filtered, etc)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
