[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634968#action_12634968
]
Doug Cutting commented on HADOOP-4044:
--------------------------------------
I still much prefer the name 'link' to 'vfs'. You use the name 'vfs' in
support of symbolic links only, and thus should be named accordingly. There's
no need to invent another name here. No one knows what a 'vfs' is, and we
don't need to define it or confuse folks with this notion. Everyone already
knows what a link is.
Can we get away with only a single implementation of the link resolver? You
already create a bogus FileStatus in the status-based link resolver, so can't
we use the same approach to implement the path-based link resolver in terms of
the status-based one, so that we only have a single implementation of the
loop-detection logic, not two?
There are still a few implementations of getSymlink() that don't throw
exceptions for non-links.
You still have not explained the necessity of getRemainingPath().
> 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.
