[
https://issues.apache.org/jira/browse/HDFS-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785734#comment-13785734
]
Colin Patrick McCabe commented on HDFS-5294:
--------------------------------------------
There are a ton of FileSystem operations that return paths. If we're going to
switch them all to return unresolve dpaths, that will also affect
getFileStatus, listStatus, getLocatedFileStatus, resolvePath,
listCorruptFileBlocks, globStatus, createSnapshot, etc.
Also, as we've discussed elsewhere, doing this would be a large performance
regression, huge in some cases.
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.
> 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)
