[jira] Updated: (HADOOP-792) Invalid dfs -mv can trash your entire dfs

["dhruba borthakur (JIRA)" <ji...@apache.org>]

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

dhruba borthakur updated HADOOP-792:
------------------------------------

    Attachment: renameerrorcode.patch

The 0.9.0 release does not have this problem. I think there was a bugfix from Konstantin in the last few weeks that addressed this issue.

When I tried your steps, the rename command failed (as expected) but the error code returned was 0. I am attaching a one-line patch that returns an error code of -1 when the rename command fails.


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