Messages in this thread | | | Date | Tue, 18 May 1999 11:41:45 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: VFAT rename |
| |
On Mon, 17 May 1999, Raul Miller wrote:
> Alexander Viro <viro@math.psu.edu> wrote: > > Sorry, I didn't realize what you were asking for. Comments re POSIX are > > correct, but in that case everything is much worse. What kind of > > semantics do you want here? Two dentries for the object at the same > > moment? Sorry, no. > > Why should this be required? > > How about: > > mark directory busy > unhash dentry > change dentry
To what? The whole bloody problem being: target dentry (which is all that represents the new name) ought to be different from the source one. Otherwise you've already forgotten the new name. Fine, but we can't allow it to be positive and hashed. Otherwise we will end up *deep* in it. So we need it unhashed. I.e. rename() (VFS one) can't use regular lookup_dentry() for target. Great. But case of mv foo Foo is not the only losing one: consider touch foo; mv bar Foo;. foo must die - this misbegotten filesystem doesn't allow foo and Foo simultaneously. OK. So target dentry should be over the inode of foo, but with the name Foo. Same problem, right? That is, on the last step of target lookup we need (a) different dentry comparison and (b) non-hashing ->lookup(). And we have to deal with the possibility of *anything* happening to namespace while we are trying to obtain the locks on directories. That thing is badly handled by the current namei.c. Witness the check_parent() kludge and stuff around its calls. You don't need much to get a really bad race here - more than enough material is already in place. "Bad" as in "once you've got it you can easily drive the thing into deadlock/fs corruption". That's the real place to be fixed.
- 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.tux.org/lkml/
| |