[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637324#action_12637324
]
Owen O'Malley commented on HADOOP-4044:
---------------------------------------
My preference is toward not using exceptions for nominal cases, and I agree
with Doug that links seem like nominal cases. Clearly, however, it isn't a slam
dunk.
At the fear of crossing streams, I think that the classes like FSLinkBoolean
are problematic. I think we are better off creating a type for each method's
return type. I think that a lot of these return types should implement a
class/interface (*Owen ducks*) that provides the common interface for
dereferencing the links.
The reason for having
{code}
RenameResult rename(Path src, Path dst) throws IOException;
FSLinkBoolean rename(Path src, Path dst) throws IOException;
{code}
would be that if we want our protocol to be future-proof, rename may well need
to add additional return values. If we have a bunch of methods all returning
the same type, that is hard.
Thoughts?
> 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.
