Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1850507866.1223662304382.JavaMail.jira@brutus>
Date: Fri, 10 Oct 2008 11:11:44 -0700 (PDT)
From: "Konstantin Shvachko (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4044) Create symbolic links in HDFS
In-Reply-To: <132525105.1219991324428.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638616#action_12638616 ] 

Konstantin Shvachko commented on HADOOP-4044:
---------------------------------------------

I am replying to this Doug's comment HADOOP-4044#action_12638405.
Was thinking about it all night and have to admit I am not quite sure how to understand it.

We were talking about the mount point exception handling on different layers of the implementation of HDFS.
Looks like that based on the references you provide checked exceptions can be used when a particular layer does not have an immediate response to the condition causing the exception.

If your comment means that you can tolerate mount point exception on all levels of HDFS implementation up to (excluding) the FileSystem api, then I anticipate a big sigh of relief from a large group of developers. And we can turn to discussion of the FileSystem api return types, which Owen is already successfully conducting.

Otherwise, my understanding of the comment is that you are introducing a new argument (line of defense) for your dual-return-type approach, and that means that we are back at the beginning and will have to start over the whole discussion again.
Please clarify.

> 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.