On Thu, May 30, 2013 at 5:45 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> The third name is because of the replace-empty-directory wart in the
> rename(2) definition. With overlay/union that can become
>
> 1) check if destination directory is empty: upper directory contains a
> whiteout for each lower directory entry and nothing else
> 2) if empty then remove whiteouts in destination directory
> 3) and then go on with the normal rename procedure, replacing the empty
> destination directory with the source directory ,
>
> This is done with directory locking, so atomicity is not usually a problem.
> But in case of a crash between 2) and 3) we just seriously corrupted the
> overlay.
>
> Suggestions for fixing that?
Why not just do the NFS thing. That has worked forever - using a
sillyrename as a "pending deletion" instead of actually deleting
things.
So in between (1) and (2), silly-rename the pseudo-empty target. At
that point (2) is no longer even an atomicity requirement, because you
can do the whiteout removal later. In fact, you probably want to do it
at the end, after doing the "real" rename.
No, it's not perfect, but it works in practice. NFS may not be POSIX,
but nobody really cares. It's usable.
> We could just refuse to do the rename-over-empty-directory and see if anyone
> complains. I don't think it's often used, but if something is documented
> then people are bound to find some stupid use for it.
I'm sure there are uses for it, since it's traditional unix behavior.
And I'm sure there are good reasons for it too (eg locking over NFS or
whatever)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
