Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Message-ID: <2126794388.1252956418454.JavaMail.jira@brutus>
Date: Mon, 14 Sep 2009 12:26:58 -0700 (PDT)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-6240) Rename operation is not consistent
 between different implementations of FileSystem
In-Reply-To: <1954163145.1252089837589.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-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755143#action_12755143 ] 

Doug Cutting commented on HADOOP-6240:
--------------------------------------

> it would be nice to simply open the file, read it, and be sure you won't fail.

Even with atomic rename/replace I'm not sure this would be guaranteed to work.  The namenode does not keep track of files open for read, so between the time that you get the file's block list from the namenode and then try to read the first block another process could replace it and that first block might no longer exist.

Something that might work is atomic rewrite of a symlink.  I have not looked at the symlink patch yet to see how it handles this, but it might be useful to support atomic replacement when both the old and the new files are symlinks.  Konstantin, does this case seem supportable long-term?


> Rename operation is not consistent between different implementations of FileSystem
> ----------------------------------------------------------------------------------
>
>                 Key: HADOOP-6240
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6240
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>             Fix For: 0.21.0
>
>
> The rename operation has many scenarios that are not consistently implemented across file systems.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.