Re: VFAT rename
H. Peter Anvin (hpa@transmeta.com)
Mon, 17 May 1999 10:27:31 -0700
>
> 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.
>
I'm sorry; I think we're talking about two different issues here. We
have established:
1. POSIX requirements don't apply here.
2. The current VFS doesn't handle it correctly.
3. This is necessary for reasonable behaviour.
Conclusion:
a. The VFS interface need to change.
I don't see why this implies multiple dentries for a directory.
-hpa
--
"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on http://www.zks.net/p3/how.asp
-
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/