[HADOOP-9507] LocalFileSystem rename() is broken in some cases when destination exists

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 1-win, 2.1.0-beta, 1.3.0, 3.0.0-alpha1
• Fix Version/s: 1-win, 2.1.0-beta, 1.3.0
• Component/s: fs
• Target Version/s: 1-win, 2.1.0-beta, 1.3.0
• Hadoop Flags: Reviewed
• Assignee: Chris Nauroth
• Reporter: Mostafa Elhemali
• Created: 25/Apr/13 21:53
• Updated: 12/May/16 18:22
• Resolved: 26/Jul/13 21:17

Description

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:

c:
cd \
md Foo
md Bar
md Foo\X
md Bar\X
hadoop fs -mv file:///c:/Foo file:///c:/Bar

At the end of this, you would expect to find only Bar\X, but you instead find Bar\X\X.

Issue Links

• is duplicated by: HADOOP-9767 RawLocalFileSystem#rename does not correctly enforce replacement of empty destination directory on all platforms
• is part of: HADOOP-8645 Stabilize branch-1-win
• is related to: HADOOP-9805 Refactor RawLocalFileSystem#rename for improved testability.