> > 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Let me reiterate: POSIX has *nothing* to do with what happens on a VFAT
> filesystem, because a VFAT filesystem (or any other case-insensitive
> filesystem) are in blatant violation of POSIX anyway. Therefore, I
> don't see any particular behaviour mandated by POSIX as relevant here
> anyway.
Wait a minute. First of all, reread the subscribed part. Now, while *some*
requirements of POSIX are, IMHO, mandatory for any fs (too many programs
depend on them) this particular one shouldn't affect VFAT in any way -
there is no links, to start with.
Considering names that differ only in capitalization as links is
dead wrong - we can't deal with links to directories. We went through that
several times. If you have a solution that allows multiple dentries for a
directory - tell it. And let me poke some holes in it, OK? So far I've
seen *no* variant that would allow this thing and wouldn't give us fs
corruption. Yup, old driver had such holes.
So far I'm convinced that the only way to allow such renames is to
change lookup() semantics for rename() target. It affects the whole
fs/namei.c and fs/dcache.c, but at least it can be done. We already have
races around lookup() and while they have no fs corruption potential now
they *will* get it if we'll just go ahead and add a new flag for lookup,
make vfat_lookup() keep the thing unhashed, etc.
-
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/