hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tsz Wo (Nicholas), SZE (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9507) LocalFileSystem rename() is broken in some cases when destination exists
Date Thu, 25 Jul 2013 22:37:49 GMT

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

Tsz Wo (Nicholas), SZE commented on HADOOP-9507:

> ... I think we need to go with the prior version of the patch that does copying. ...

Does HADOOP-9507-trunk.3.patch work of separated drives?  The approach in it seems the best.
 It first tries (1) rename, then (2) delete & rename for copying src dir to empty dst
dir, and finally (3) copy.  If yes, +1 on the patch.  If it does not work for separated drives,
I am fine to commit the prior version, +1 on that patch too.  Thanks for checking it.

I will take a look at TestLightWeightCache.  It definitely is not related to this.
> LocalFileSystem rename() is broken in some cases when destination exists
> ------------------------------------------------------------------------
>                 Key: HADOOP-9507
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9507
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs
>    Affects Versions: 3.0.0, 1-win, 2.1.0-beta, 1.3.0
>            Reporter: Mostafa Elhemali
>            Assignee: Chris Nauroth
>            Priority: Minor
>         Attachments: HADOOP-9507-branch-1.1.patch, HADOOP-9507-branch-1.3.patch, HADOOP-9507-branch-1-win.1.patch,
HADOOP-9507-branch-1-win.3.patch, HADOOP-9507.branch-1-win.patch, HADOOP-9507-trunk.1.patch,
HADOOP-9507-trunk.2.patch, HADOOP-9507-trunk.3.patch
> The rename() method in RawLocalFileSystem uses FileUtil.copy() without realizing that
FileUtil.copy() has a special behavior that if you're copying /foo to /bar and /bar exists
and is a directory, it'll copy /foo inside /bar instead of overwriting it, which is not what
rename() wants. So you end up with weird behaviors like in this repro:
> {code}
> c:
> cd \
> md Foo
> md Bar
> md Foo\X
> md Bar\X
> hadoop fs -mv file:///c:/Foo file:///c:/Bar
> {code}
> At the end of this, you would expect to find only Bar\X, but you instead find Bar\X\X.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message