[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635006#action_12635006
]
dhruba borthakur commented on HADOOP-4044:
------------------------------------------
@Doug: Ok, I will post a new patch very soon.
getRemainingPath() returns the trailing path components that could not be
resolved by a file system implementation.
Suppose one is trying to resolve hdfs://home/dhruba/link/dir/file.txt and link
is a symbolic link pointing to file:///etc, then getSymlink() will return
file:///etc and getRemainingPath() will return dir/file.txt. Now,
FileSystem.java will use these two components to create a new path. Are you
saying that getSymlink() can return file:///etc/dir/file.txt?
@Raghu: UnresolvedPathException is a namenode private class. It is not thrown
to the dfs client. The Namenode catches this exception, maps it to FSLink
object and returns it to the client.
> Create symbolic links in HDFS
> -----------------------------
>
> Key: HADOOP-4044
> URL: https://issues.apache.org/jira/browse/HADOOP-4044
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: symLink1.patch, symLink1.patch, symLink4.patch,
> symLink5.patch, symLink6.patch
>
>
> HDFS should support symbolic links. A symbolic link is a special type of file
> that contains a reference to another file or directory in the form of an
> absolute or relative path and that affects pathname resolution. Programs
> which read or write to files named by a symbolic link will behave as if
> operating directly on the target file. However, archiving utilities can
> handle symbolic links specially and manipulate them directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
