I don't think too much arises. An open is atomic, an unlink is atomic, a
rename is atomic. The directory moves before or after the operation not
during. We get to pick if we want to present the move as before or after.
So a rename of the parent of an open is valid. We either open the file in
the new name space or return -ENOENT. [According to the order we present].
Similarly with unlink, mkdir, rmdir.
We do however also have to cover paths relative to '.' - where moves
higher in the name tree do not have any affect on our open anyway, and
threads doing a chdir or chroot while another thread opens. That part of
our dentry path is capable of changing above us and should rightfully do so
without affecting a pending operation and where it goes.
We have no "frename" or "funlink" (fortunately ;)), so the only really
horrible one appears to be umount(). And the semantics of umount arent
even defined in the single unix spec.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html