[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637240#action_12637240
]
Konstantin Shvachko commented on HADOOP-4044:
---------------------------------------------
The code looks bizarre (or unclean) with all the FSLink*** return types.
I do not like when exceptions are used for normal control flow.
But looking at what it takes to avoid it I lean to the idea that may be this
is the exceptional case when we should divert from the general principles.
I see two compromise solutions.
# Introduce a new method {{Path getSymLink(Path src)}}, which returns first
symbolic link in the {{src}} path.
Then all methods {(create(), getBlockLocations(), rename()}}, etc. can throw
the {{UnresolvedPathException}} all the way to the application via FileSystem
API. The application can then call {{getSymLink()}} to resolve the mount point.
{{UnresolvedPathException}} should be a regular subclass of IOException without
any hints on how the sym link should be resolved.
I understand that local links are resolved on the name-node.
So {{UnresolvedPathException}} is thrown only when a mount point is crossed.
This is uncommon and should not be optimized.
The application itself should call {{getSymLink()}} after either receiving the
{{UnresolvedPathException}} or if it knows about the mount point from its
previous activity.
# Another "clean" way to handle this would be to introduce output parameters in
RPC framework.
In current RPC all arguments are input only and the only way to return a value
is by explicitly specifying the return value of the protocol method.
And if you need to return several values you have to wrap them into an object.
This is exactly what makes FSLink*** so ugly.
If we had a way to specify that some arguments are output values then the api
would more reasonable. E.g.
{code}
public FSLink getFileInfo(String inSrc, FileStatus outStatus) throws
IOException;
{code}
vs
{code}
public FSLinkFileStatus getFileInfo(String src) throws IOException;
{code}
> 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.
