mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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




             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®