[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637268#action_12637268
]
Doug Cutting commented on HADOOP-4044:
--------------------------------------
> The code looks bizarre (or unclean) with all the FSLink*** return types.
It does look different than the FS API always has looked, and different than
other FS apis. But to reject it for just looking different, to call it
bizzarre and unclean, is xenophobia. It *is* different. Other FSs (e.g.,
linux VFS) don't try to do this in a single call, but rather loop, checking
whether each element in the path is a link. If we wish to avoid that, then we
must pack more data into the return types of our API, and our API will look
different. We can try to hack around that by using exceptions or thread locals
or output parameters, but those are all just attempts to try to make this API
look like other APIs rather than embrace its differences.
So, do we really want to handle links in a single call? I think so.
> 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.
