Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 11506 invoked from network); 9 Oct 2008 23:25:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2008 23:25:41 -0000 Received: (qmail 71569 invoked by uid 500); 9 Oct 2008 23:25:34 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 71533 invoked by uid 500); 9 Oct 2008 23:25:34 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 71515 invoked by uid 99); 9 Oct 2008 23:25:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2008 16:25:34 -0700 X-ASF-Spam-Status: No, hits=-1999.9 required=10.0 tests=ALL_TRUSTED,DNS_FROM_SECURITYSAGE X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2008 23:24:37 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 56B1C234C22B for ; Thu, 9 Oct 2008 16:24:44 -0700 (PDT) Message-ID: <795916764.1223594684354.JavaMail.jira@brutus> Date: Thu, 9 Oct 2008 16:24:44 -0700 (PDT) From: "Doug Cutting (JIRA)" 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 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638430#action_12638430 ] Doug Cutting commented on HADOOP-4044: -------------------------------------- Owen, do you think this logic is unique to HDFS? If we add support for links to another FileSystem implementation would we want to share this logic with HDFS? If so, could we do it through a common base-class, like LinkableFileSystem. Then FileSystems that never intend to support links could continue to directly implement the end-user methods, while FileSystems that support links would extend the new subclass and implement the LinkResult SPI methods. Is that consistent with your proposal? Also, the pseudo code above will cause a stack overflow for a circular link. Shouldn't we catch loops earlier than that? And if the loop-detection logic is non-trivial, won't we end up with either lots of duplicated code or something like the anonymous classes in Dhruba's patch? > 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.