Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

[Al Viro]

On Thu, May 14, 2015 at 07:18:16PM -0700, Linus Torvalds wrote:
> The only difference - EVER - would be if you pass in the ICASE flag.
> Nothing I suggested would change semantics without it (the _hash_
> changes, but that doesn't change semantics, it's a purely internal
> random number).
> 
> Now, *with* O_ICASE/AT_ICASE, semantics change. Obviously. At that
> point the dentry lookup would match case-insensitively.
> 
> For example, let's say that you have a directory where you already
> have both "Blah" and "blah", because you created them in a sane
> environment. They'll be two different dentries (assuming they are
> cached), but they'll have the same dentry hash.
> 
> Now, you open "blah" with O_ICASE, and the end result is that you
> would randomly open one or the other (it would be the one you find
> first on the hash chain). Tough. Mixing icase and case-insensitive is
> by definition going to cause those kinds of issues.

With c-i mount, unpacking a tarball with tar(1) will not (silently, at that)
create a situaiton when your c-i users will get lookups proceeding into
randomly picked variant of directory, with variants differing only in
case.  It will do the right thing and put the files where they would be
expected, giving an expected "it already exists" if you try to create
a directory with the name that matches that of existing file, etc.
With this, OTOH, you'll have to use specialized tools for creating
files in that tree, or risk random lossage, because creating /mnt/foo/bar
when /mnt/Foo/Bugger already existed will succeed just fine, leaving one
hell of a mess for c-i users.

What's the benefit compared to c-i mount?  Not hitting filesystem's
->d_hash() and ->d_compare()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/