[
https://issues.apache.org/jira/browse/HADOOP-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702808#comment-13702808
]
Colin Patrick McCabe commented on HADOOP-9418:
----------------------------------------------
{code}
// Don't to a recursive resolve since it requires a full-fledged DFS
{code}
Grammar. Also, can you be clearer in the comment about why the regular
delete() won't work here?
{code}
protected RemoteIterator<LocatedFileStatus> listLocatedStatus(final Path p,
final PathFilter filter)
throws IOException {
...
// Fully resolve symlinks in path first
src = getPathName(resolvePath(p));
{code}
It's not clear to me why the source path needs to be resolved here. Certainly,
POSIX doesn't do this in stat(). Doing this here adds an extra getFileStatus
call to the NN (including the round-trip). I guess the argument is that since
symlink resolution is done client-side, the NN can't handle a path with
symlinks in it? Unfortunately, that raises the question of what happens when
someone changes our "fully resolved" path to include a symlink in between
resolvePath() and the call to {{namenode.getListing}}.
> Add symlink resolution support to DistributedFileSystem
> -------------------------------------------------------
>
> Key: HADOOP-9418
> URL: https://issues.apache.org/jira/browse/HADOOP-9418
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs
> Affects Versions: 3.0.0
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Attachments: hadoop-9418-1.patch, hadoop-9418-2.patch,
> hadoop-9418-3.patch, hadoop-9418-4.patch, hadoop-9418-5.patch
>
>
> Add symlink resolution support to DistributedFileSystem as well as tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
