public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Shimmin <tes@sgi.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: linux-xfs@oss.sgi.com, Gerald Bringhurst <gbringhurst@novell.com>,
	Brandon Philips <bphilips@suse.de>
Subject: Re: acl and attr: Fix path walking code
Date: Tue, 20 Nov 2007 16:11:12 +1100	[thread overview]
Message-ID: <47426C70.3070704@sgi.com> (raw)
In-Reply-To: <473A82E6.50709@sgi.com>

> 
> 
>  > On Friday 09 November 2007 08:39:56 Timothy Shimmin wrote:
>  >> > You mention -L/-P is like chown.
>  >> > However, -P for getattr isn't about not walking symlinks
>  >> > to directories,
>  >> > it's about skipping symlinks altogether, right?
>  >
>  > Hmm, -L and -P define which files and directories are visited, and -h 
> defines
>  > whether we are looking at symlinks or the files they point to. The two
>  > concepts are orthogonal. -P is not about skipping symlinks, only 
> about not
>  > recursing into them.
>  >
> Oh okay.
> There is the concept of following the symlink for traversal versus
> following the symlink to get the EA on.
> 
> So with -L should it just follow the symlink or look at the symlink first
> and then follow it?
> And will -h modify this behavior?
> I'm still confused about the 1st difference in 062 output.
> 
> I wonder if the man pages can be clarified in this area :)
> 
> --Tim
> 

Okay, looked at the code.

---

no -h => stat, getxattr, listxattr
-h    => lstat, lgetxattr, llistxattr

-P => skip symlinks (as soon as see them, then return from place in walk)

-L => process symlink and then opendir on symlink (hence follow/traverse it)

default => -L for argument (depth==1) and -P for subdirs (depth>1)

----

This was different than my intuition.
I am happy with -h.
For -P, I was expecting it to process symlink but not follow/traverse it,
I wouldn't think it should just skip them altogether (I realise the
man page says that).

For -L, I wasn't sure if it should process it first and then traverse
or simply just traverse.

So were these your intentions?
If so, the code seems to follow them but it would be nicer to
have more explanation in the man page.

--Tim

  reply	other threads:[~2007-11-20  5:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-28 17:58 acl and attr: Fix path walking code Andreas Gruenbacher
2007-11-09  5:41 ` Timothy Shimmin
2007-11-10 20:52   ` Andreas Gruenbacher
2007-11-14  5:08     ` Timothy Shimmin
2007-11-20  5:11       ` Timothy Shimmin [this message]
2007-11-23 12:24         ` Andreas Gruenbacher
2007-11-09  7:39 ` Timothy Shimmin
2007-11-10 21:36   ` Andreas Gruenbacher

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=47426C70.3070704@sgi.com \
    --to=tes@sgi.com \
    --cc=agruen@suse.de \
    --cc=bphilips@suse.de \
    --cc=gbringhurst@novell.com \
    --cc=linux-xfs@oss.sgi.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