xfs
[Top] [All Lists]

Re: [NEWS] Extended attributes interface changes

To: Ethan Benson <erbenson@xxxxxxxxxx>
Subject: Re: [NEWS] Extended attributes interface changes
From: Nathan Scott <nathans@xxxxxxx>
Date: Sun, 3 Feb 2002 21:23:33 +1100
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20020203010129.C14742@xxxxxxxxxxxxxxx>; from erbenson@xxxxxxxxxx on Sun, Feb 03, 2002 at 01:01:29AM -0900
References: <20020201101545.G88469@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.44.0202021151090.5765-100000@xxxxxxxxxxxxxxxxxxxxxxxxx> <20020201213849.Y14742@xxxxxxxxxxxxxxx> <"from <20020203204959.A104774@xxxxxxxxxxxxxxxxxxxxxxxx> <20020203010129.C14742@xxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Sun, Feb 03, 2002 at 01:01:29AM -0900, Ethan Benson wrote:
> On Sun, Feb 03, 2002 at 08:49:59PM +1100, Nathan Scott wrote:
> > > does that mean libacl will need to know about the on disk format for
> > > ACL extended attributes for each filesystem it supports? 
> > > 
> > 
> > No, we'll convert to/from a common (VFS) format into the XFS-specific
> > format before writing / after reading the ACL.
> 
> hmm, but as im understanding this libacl will just be writing an
> extended attribute to a file, how will XFS, or whatever know this
> attribute is for ACLs rather then just some arbitrary attribute? 

attributes in the system namespace will need to be converted to
the native filesystem format before/after being written/read.

> the acl.bestbits.at site is rather light on technical info..

yes, we'll need to improve some areas of the documentation -
several people have pointed this out now.

cheers.

-- 
eNathan


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