unionfs_rename

[rpodgorny]

from ancient email:

Hi,

while looking into code to find an issue, I reviewed the unionfs_rename() code. If the code and the logic seem correct, two things made me uneasy:

- before rename, you check if branch from which comes the files is writable. In case it's not, you would create a whiteout. If that's a good idea, reading through your code shows that if the said branch is not writable, you immediately perform a copy on write or fail. So, in fact, once you reach that point to verifiy, the branch on which is the file is writable. That piece of code won't be executed.

- after rename, if it succeed, you rechecked if branch is writable, and if yes, you call functions to possibly create whiteouts. This case will always be right.

It just looks you might have mixed two algorithms. As far as I get you code and the way it works, it would just be possible to get rid of first check (and all dead code) just to keep second code (removing check as well). This wouldn't change anything to what is effectively done, but get logic back:
- You ensure you can rename file by copying if needed
- You rename
- You hide from file if needed.

I hope my explanations were clear enough since I can't send you any patch (due to CERN internal modifications).

With best regards,
P. Schweitzer