Let's assume there's a file /usr/schmidt/file1 that has been recently raided. In that case, the RaidNode will have crated a parity file /raid/usr/schmidt/file1
Now, imagine the user rewrites its original file and creates a new version of /usr/schmidt/file1.
The RaidNode correctly identifies the file has to be re-raided, creates the parity file in a temporary directory, but when it tries to move the newly created parity file from the temporary directory to /raid/usr/schmidt/file1, it fails because the destination already exists.
The patch verifies if the destination exists before renaming it and deletes the file in that case.
The unit test covers this scenario.
I actually found this bug when you proposed to add the unit test that covers this scenario on my patch to
MAPREDUCE-1510. I didn't want to fix this bug there because MAPREDUCE-1510 was an improvement and not a bug, and (ii) neither the title or the description of MAPREDUCE-1510 covers this failure scenario and people looking for this problem would have a hard time finding the correct JIRA.