Attaching patches to fix this code path for trunk and Yahoo! 20 branch. The problem is as described, rather than stopping the delete, we swallow the exception and proceed. These patches fix that and toss the exception received from mkdirs up to FsShell. After patch, the file is not remains, the user is notified of the exception and the exception is logged.
Ran tests (all fine) and test-patch on trunk version:
[exec] +1 overall.
[exec] +1 @author. The patch does not contain any @author tags.
[exec] -1 tests included. The patch doesn't appear to include any new or modified tests.
[exec] Please justify why no new tests are needed for this patch.
[exec] Also please list what manual steps were performed to verify this patch.
[exec] +1 javadoc. The javadoc tool did not generate any warning messages.
[exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
[exec] +1 findbugs. The patch does not introduce any new Findbugs warnings.
[exec] +1 release audit. The applied patch does not increase the total number of release audit warnings.
Tests and test-patch for Y! 20 release still pending. Will update.
Reason for no tests: This is very difficult code path to test and we're doing it manually. This entire method should be refactored: there are like 10 different ways to get out of the method and its tests re-written, since this has been the source of several bugs. I'll open a JIRA shortly to do this. For now, I believe a manual test will suffice and drive the next set of automatic tests.