Re: mtree acl support

From: Edward Tomasz Napierała <trasz_at_FreeBSD.org>
Date: Thu, 16 Jan 2014 23:09:16 +0100
Wiadomość napisana przez Mark Felder w dniu 16 sty 2014, o godz. 21:36:
> On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote:
>> 
>> On Jan 14, 2014, at 6:47 AM, Mark Felder <feld_at_freebsd.org> wrote:
>> 
>>> I was recently talking to someone about how one would backup / restore
>>> ACLs reliably. I didn't see any mention of ACLs in the mtree man page
>>> and after a quick google I came upon this old mailing list post:
>>> 
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
>>> 
>>> patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff
>>> I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff
>>> 
>>> This old patch appears to still apply cleanly. I hate to see a patch die
>>> and be forgotten.
>> 
>> One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s
>> work on star) is to permit ACLs to be restored even if the user database
>> is out of date.
>> 
>> This is done by including a fourth field in each ACE with the
>> numeric user ID.
>> 
>> I suspect you want to do the same for mtree.  I thought
>> I remembered acl_to_text having an option to use
>> an extended text format, so it might be a trivial change.
>> 
> 
> As long as it's not default. One of the most convenient ways to change a
> user's UID (or multiple users!) is to do an mtree backup, change
> UID/GID, and then re-apply mtree backup. Every file that the user(s)
> previously owned will be automatically changed to the new UID/GID for
> you :-)

I don't think the functionality above would interfere with that in any way.
The owner entries ("user:" for POSIX, "owner_at_" for NFSv4 ACLs) are stored
in a different way, and they never have the appended ID.

(Besides, why not just "find ./ -user XXX -print0 | xargs -0 chown YYY"?)

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?
Received on Thu Jan 16 2014 - 21:09:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC