xfs
[Top] [All Lists]

Re: acl and attr: Fix path walking code

To: Andreas Gruenbacher <agruen@xxxxxxx>
Subject: Re: acl and attr: Fix path walking code
From: Timothy Shimmin <tes@xxxxxxx>
Date: Wed, 14 Nov 2007 16:08:54 +1100
Cc: linux-xfs@xxxxxxxxxxx, Gerald Bringhurst <gbringhurst@xxxxxxxxxx>, Brandon Philips <bphilips@xxxxxxx>
In-reply-to: <200711102152.05619.agruen@suse.de>
References: <200710281858.24428.agruen@suse.de> <4733F301.9020706@sgi.com> <200711102152.05619.agruen@suse.de>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
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


<Prev in Thread] Current Thread [Next in Thread>