Re: acl and attr: Fix path walking code

[Timothy Shimmin <tes@sgi.com>]

Andreas Gruenbacher wrote:
 > On Friday 09 November 2007 06:41:21 Timothy Shimmin wrote:
 >> I applied attr patch and tried it out on xfstests/062
 >> (which I believe was based on one of your tests).
 >>
 >> ==========================================================
 >> --- 062.out     2006-03-28 12:52:32.000000000 +1000
 >> +++ 062.out.bad 2007-11-09 15:38:09.000000000 +1100
 >> @@ -526,6 +526,10 @@
 >>   user.name=0xbabe
 >>   user.name3=0xdeface
 >>
 >> +# file: SCRATCH_MNT/lnk
 >> +trusted.name=0xbabe
 >> +trusted.name3=0xdeface
 >> +
 >>   # file: SCRATCH_MNT/dev/b
 >>   trusted.name=0xbabe
 >>   trusted.name3=0xdeface
 >> @@ -562,6 +566,10 @@
 >>   user.1=0x3233
 >>   user.x=0x797a
 >>
 >> +# file: SCRATCH_MNT/descend/and/ascend
 >> +trusted.9=0x3837
 >> +trusted.a=0x6263
 >> +
 >>
 >>   *** directory descent without following symlinks
 >>   # file: SCRATCH_MNT/reg
 >> ==========================================================
 >>
 >> So for the following of symlinks with getfattr -L
 >> i.e.
 >>    echo "*** directory descent with us following symlinks"
 >>    getfattr -h -L -R -m '.' -e hex $SCRATCH_MNT
 >>
 >> Looking at the 2nd difference...
 >> It now picks up descend/and/ascend which contains the symlink
 >> of descend/and --> here/up.
 >> So that makes sense, it is following a symlink which it
 >> didn't before and finding a dir, "up" in the linked dir.
 >> Good.
 >>
 >> Looking at 1st difference...
 >> It is now showing up "lnk" which is a symlink: lnk --> dir
 >> So why is it showing this up
 >> and yet it is not showing descend/and (which is a link to here/up)?
 >> So yes we are following symlinks but are we supposed
 >> to just do the symlinks themselves as well?
 >
 > With -h, the utilities operate on the symlinks rather than the files that the
 > symlinks point to. The test case sets attributes on SCRATCH_MNT/lnk, but not
 > on descend/and.

Oops, yep, there is no EA on descend/and.

 >
 > The -h and -L options together don't make much sense actually.
 >
No they don't :)
So will it not follow the argument but follow any descendents that
it finds on the walk.
It kind of looked from the manpage that the -h is about just
the argument and not about the walk.

<okay you clarified this below...>

Anyway, I took out the -h with the -L,
i.e. $ getfattr  -L -R -m '.' -e hex $SCRATCH_MNT

And it is still reporting
 >> +# file: SCRATCH_MNT/lnk
 >> +trusted.name=0xbabe
 >> +trusted.name3=0xdeface
 >> +

So I presume following symlinks also mean operating on symlinks too
(i.e. getting the EA)?

---


 > 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