[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: VFAT rename

On Mon, 17 May 1999, Raul Miller wrote:

> Alexander Viro <> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:11.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site