[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638405#action_12638405
]
Doug Cutting commented on HADOOP-4044:
--------------------------------------
Konstantin> this argument is about the programming style rather than
performance or anything else
It's clearly about both of those. We wish to make a change motivated by
performance, and the question is how best to implement that change. We have
two proposals on the table, one that is less invasive but uses a discouraged
style, and one that involves substantial changes but avoids that style problem.
I tried earlier to remove the discussion from style guidelines to the
underlying reason for those guidelines --that an API's purpose is to model
expected control and data flow--but that argument seems to have caused more
confusion than it has helped, so I've mostly reverted to citing style
guidelines.
Konstantin> FileSystem is the first layer for which link values make sense.
The fact that that layer is fully-resolved and known indicates that links
should be a first-class value in the API. All of the other layers you present
are part of a single module (HDFS) whose job is to present itself as a
FileSystem. If HDFS is implementing the FileSystem API, then FileSystem's
datatypes are not alien to HDFS. This is the same twist that Sanjay pursued.
Yes, the link URI is to a file outside of that particular HDFS filesystem, but
link URIs are normal data that HDFS accepts as parameters (when adding a
symbolic link), stores, and returns (when dereferencing a link). So this is
not an alien object or an unexpected situation. A link to another filesystem
is a sensible, first class value within HDFS.
> 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, symLink8.patch, symLink9.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.
