Received: with ECARTIS (v1.0.0; list xfs); Sat, 10 Nov 2007 12:52:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.0-r574664 Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lAAKq1xu000587 for ; Sat, 10 Nov 2007 12:52:03 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 660A51AA4C; Sat, 10 Nov 2007 21:52:07 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs To: Timothy Shimmin Subject: Re: acl and attr: Fix path walking code Date: Sat, 10 Nov 2007 21:52:05 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: linux-xfs@oss.sgi.com, Gerald Bringhurst , Brandon Philips References: <200710281858.24428.agruen@suse.de> <4733F301.9020706@sgi.com> In-Reply-To: <4733F301.9020706@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711102152.05619.agruen@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4745/Sat Nov 10 02:50:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13607 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs 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. The -h and -L options together don't make much sense actually. > BTW, do we not allow user EAs on symlinks? (I've forgotten) No we don't --- that's explained on attr(5). Thanks for looking at this! Andreas