[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230720074318.GA56170@sol.localdomain>
Date: Thu, 20 Jul 2023 00:43:18 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Gabriel Krisman Bertazi <krisman@...e.de>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, tytso@....edu,
jaegeuk@...nel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH v3 0/7] Support negative dentries on case-insensitive
ext4 and f2fs
Sorry, one more thing...
On Wed, Jul 19, 2023 at 06:19:11PM -0400, Gabriel Krisman Bertazi wrote:
>
> Another problem exists when turning a negative dentry to positive. If
> the negative dentry has a different case than what is currently being
> used for lookup, the dentry cannot be reused without changing its name,
> in order to guarantee filename-preserving semantics to userspace. We
> need to either change the name or invalidate the dentry. This issue is
> currently avoided in mainline, since the negative dentry mechanism is
> disabled.
Are you sure this problem even needs to be solved?
It actually isn't specific to negative dentries. If you have a file "foo"
that's not in the dcache, and you open it (or look it up in any other way) as
"FOO", then the positive dentry that gets created is named "FOO".
As a result, the name that shows up in /proc/$pid/fd/ for anyone who has the
file open is "FOO", not the true name "foo". This is true even for processes
that open it as "foo", as long as the dentry remains in the dcache.
No negative dentries involved at all!
Is your thinking that you just don't want to increase the number of ways in
which this behavior can occur?
Or, it looks like the positive dentry case is solvable using d_add_ci().
So maybe you are planning to do that? It's not clear to me.
- Eric
Powered by blists - more mailing lists