Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <31114165.1165961662304.JavaMail.jira@brutus>
Date: Tue, 12 Dec 2006 14:14:22 -0800 (PST)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Updated: (HADOOP-792) Invalid dfs -mv can trash your entire
 dfs
In-Reply-To: <7912715.1165469301076.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/HADOOP-792?page=all ]

Doug Cutting updated HADOOP-792:
--------------------------------

           Status: Resolved  (was: Patch Available)
    Fix Version/s: 0.10.0
       Resolution: Fixed

I just committed this.  Thanks, Dhruba!

> Invalid dfs -mv can trash your entire dfs
> -----------------------------------------
>
>                 Key: HADOOP-792
>                 URL: http://issues.apache.org/jira/browse/HADOOP-792
>             Project: Hadoop
>          Issue Type: Bug
>    Affects Versions: 0.5.0
>            Reporter: Chris Schneider
>             Fix For: 0.10.0
>
>         Attachments: renameerrorcode.patch
>
>
> If the target path of the dfs -mv command exists within the source path, the dfs becomes corrupt. For example:
> % hadoop dfs -mkdir target
> % hadoop dfs -mv / target
> I'm not certain whether this is reproducible in the current trunk, but I'd bet that it is.
> This problem successfully circumvented my own patch to make dfs -rm a little safer (see my email c.2006-08-30 to nutch-dev for details). I had been deleting old crawl directories from the DFS by copying their names and pasting them into my command buffer. At one point, I paused to do something else, copied some other text (which unfortunately began with a Java comment and included carriage returns), then went back to removing the crawl directories. I must not have pressed hard enough on the "c" key when I did my next copy, since when I pasted into the command buffer, hadoop immediately began executing a dfs -rm / command. No problem - I'm protected, because my patched dfs command is just going to try to move / to /trash (and fail), right?
> Wrong! Even though hadoop isn't really capable of such a move, it apparently tries hard enough to corrupt the namenode's DB.
> Thankfully, I ran into this problem at a relatively opportune time, when the contents of my dfs had little value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira