From: "David Dabbs" <david@dabbs.net>
To: "'ReiserFS List'" <reiserfs-list@namesys.com>,
<linux-kernel@vger.kernel.org>
Cc: <viro@parcelfarce.linux.theplanet.co.uk>,
"'Alex Zarochentsev'" <zam@namesys.com>
Subject: Re: [PATCH] use S_ISDIR() in link_path_walk() to decide whether the last path component is a directory
Date: Mon, 13 Sep 2004 16:34:15 -0500 [thread overview]
Message-ID: <20040913213429.6813115CA8@mail03.powweb.com> (raw)
>viro wrote
>On Mon, Sep 13, 2004 at 11:49:22AM +0400, Alex Zarochentsev wrote:
> Hi,
>
> This patch does not allow open(name, O_DIRECTORY) to be successful for
> non-directories in reiser4. It replaces ->i_op->lookup != NULL "is dir"
> check for the last path component by explicit S_ISDIR(->i_mode) check.
>
> Regardless to reiser4, S_ISDIR() looks more clear there.
>
>The only objection here is that right now we are guaranteed that cwd and
>root of every task have non-NULL ->lookup(). With your patch all we have
>is S_ISDIR().
>
>So we either need to check for non-NULL ->lookup() before the beginning of
>loop in link_path_walk() or split the flag in two. I would rather do the
>former...
>
I'm working on something similar, but with alternate pathname resolution
when the path begins with exactly two slashes. Only pseudocode here because
I do not have access to my box:
In path_lookup()
if (*name == '/') {
if (*(name+1)=='/' && *(name+2)==':') {
name+=3;
nd->flags &= LOOKUP_SLASHSLASH
if (*name!='/')
goto relative;
}
In link_path_walk()
When LOOKUP_SLASHSLASH, handle names as follows:
If this !S_ISDIR()
next.name Behavior
------------------------------------------------------
. Same if i_op && i_op->lookup, else -ENOTDIR.
.. Same.
... Okay if i_op && i_op->lookup, else -ENOTDIR.
otherwise Fails with -ENOENT.
If S_ISDIR()
any Same behavior
I tested the //: & flag code and this works (in my limited testing yesterday
with bash and some test programs).
This should limit "hybrid" file-directories to only one valid subdirectory,
the "special metadata" directory. Thus, if a new/modified app wants to
create/access metadata, it would do something like the following:
# relative path
cd /test
touch foo.txt
mkdir foo.txt/... # FAILS
mkdir //:foo.txt/...
echo JayRandom > //:foo.txt/.../Author
# absolute path
echo blahblah > //:/test/foo.txt/.../Title
mkdir testdir
mkdir //:testdir/...
echo no > //:testdir/.../VirusScan
Yes, this means that a) ... is "removed" from the namespace and b) directory
metadata directories are visible to naïve applications/users while those for
files are not. But it does provide "metadata-aware" apps/users a consistent
way to access this info for both files and directories without resorting to
openat(). Since SuS provides for "implementation-specific" pathname
resolution when pathnames begin with exactly two slashes this should be
legal(?), if desired.
This doesn't address the issue of "active" metadata objects such as reiser4
provides e.g. foo.txt/metas/perms. That's a different discussion.
David
next reply other threads:[~2004-09-13 21:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 21:34 David Dabbs [this message]
2004-09-13 22:26 ` viro
-- strict thread matches above, loose matches on Subject: below --
2004-09-13 7:49 Alex Zarochentsev
2004-09-13 15:43 ` viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040913213429.6813115CA8@mail03.powweb.com \
--to=david@dabbs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-list@namesys.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
--cc=zam@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®