| To: | Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [NEWS] Extended attributes interface changes |
| From: | Ethan Benson <erbenson@xxxxxxxxxx> |
| Date: | Sun, 3 Feb 2002 01:01:29 -0900 |
| In-reply-to: | <20020203204959.A104774@xxxxxxxxxxxxxxxxxxxxxxxx>; from nathans@xxxxxxx on Sun, Feb 03, 2002 at 08:49:59PM +1100 |
| Mail-copies-to: | nobody |
| Mail-followup-to: | Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx> |
| References: | <20020201101545.G88469@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.44.0202021151090.5765-100000@xxxxxxxxxxxxxxxxxxxxxxxxx> <20020201213849.Y14742@xxxxxxxxxxxxxxx> <"from erbenson"@alaska.net> <20020203204959.A104774@xxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
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? the acl.bestbits.at site is rather light on technical info.. -- Ethan Benson http://www.alaska.net/~erbenson/
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | TAKE - xfsprogs, Nathan Scott |
|---|---|
| Next by Date: | Re: [NEWS] Extended attributes interface changes, Nathan Scott |
| Previous by Thread: | Re: [NEWS] Extended attributes interface changes, Nathan Scott |
| Next by Thread: | Re: [NEWS] Extended attributes interface changes, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |