On 17 May 1999, H. Peter Anvin wrote:

> > It's a feature. That is, an idiotic bug in standard. Nothing to do here.
> > 
> 
> No, it's not.  VFAT is not a POSIX-compliant filesystem
> (case-insensitivity is explicitly forbidden), so it is not required to
> behave that way.

Awww... OK, let me try to sort it out. There are several issues here.
1. VFAT requirement to have FoO equivalent to fOo. Notice that if you'll
mount the thing with check=strict the problem with rename() should go
away.
2. Uniform handling of ->lookup(). That way we are getting positive lookup
on a new name. Can be changed (that will also remove the problem), but
there are some tricky races with that thing. They can be dealt with, but
it is not trivial. Essentially we'll need an equivalent of struct
nameidata. It would be The Right Thing(tm) anyway, but getting the thing
to alpha stage will take a week or so. I'm doing it anyway (for completely
different reasons).
3. Old handling of aliases was utterly broken. From the VFS point of view 
it gave us hardlinks to directories. Restore this code and you'll get
*many* races to deal with. I've dealt with this code for long and I'm
fairly sure that there is no race-free way to handle it.
4. POSIX has a bug in dealing with rename("foo","bar") when both foo and
bar point to the same file. Apparently they wanted to prohibit collapsing
case (i.e. rename("foo","foo");) and screwed up with wording. Or maybe
not. Anyway, it's history now.
5. #1, #2 and #3 brought us to the situation when rename("foo","Foo")
triggered a check mandated by #4. They shouldn't - "Foo" should be
considered negative in that context. Other than that POSIX has nothing to
this situation - I've misparsed original posting.

HTH.
	Al


-
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/