[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638108#action_12638108
]
Doug Cutting commented on HADOOP-4044:
--------------------------------------
> why don't we accept the solution that does not require any fundamental
> changes to the FileSystem API
But it *does* change the API fundamentally. All of these methods are now
conditional. They now either return the declared value or a boolean indicating
that the declared value is to be ignored and that one should follow up with a
request for the link value. That's a substantial change, that shouldn't be
cloaked in exception handling.
We might instead consider changing the contract of these methods to permit the
return of a null value, and interpret a null value as the need to request the
link value. Unfortunately that won't work with the boolean methods, and it's a
fragile approach, since folks might forget to check for null. It's better to
make it explicit with a datastructure.
> My proposal does "not double the number of RPCs per file operation".
I did not mean to imply that it did. I'm sorry that you thought I did. When I
referred to doubling the number of RPCs I was contrasting with the naive
approach of calling resolveLink() or somesuch explicitly before open(), so that
open() is never passed a path that contains a link, as this is implemented in
Unix and other VFSs.
Your approach would add an RPC whenever a symbolic link is encountered over the
other approaches, since the link value would not be returned directly with the
call to open() but would require a second RPC, right?
> I keep wondering what is your selective criteria for ignoring some arguments
> and answering other.
What arguments am I ignoring? I am sorry if you feel I've ignored some of your
arguments. Please highlight them, if you like.
> 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.
