[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] xattr support on Linux

From: Pavel Raiskup
Subject: Re: [Bug-tar] xattr support on Linux
Date: Thu, 04 Oct 2012 15:28:40 +0200

Jörg, thanks for discussion,

>>> I've held off through a combination of wanting to stay as close as
>>> possible to the upstream sources and an apparently erroneous assumption
>>> that with several xattr patches floating around that eventually one
>>> would be merged.
>>> What's the story here?  Are there plans to add xattr support to tar?  If
>>> not, would it help if I pick one, merge it, and expose it, say, through
>>> inclusion in Debian's experimental tree?
>> Bdale, thanks for touching this important topic.  I just want to ask you
>> whether there is xattr patch other than Fedora originated?  It could look
>> like there is several xattr patches but AFAIK it is still the single one
>> xattrs patch applied in Fedora/Gentoo/RHEL but with several incremental
>> improvements (both from Gentoo/RH side).  If you are considering this, be
>> sure you have at least checked the last updated version:
> star supports Linux xattrs since 2003.

yep, and it is also "some time" since people from RH/Fedora trying to
propose this into GNU upstream tar also -- AFAIK since 2006.  For this
time is shipped patched GNU tar with xattr in Fedora (as you can see -
compatible with star's "SCHILY.*" pax headers..).

> Note that Linux xattrs are not compatible to the xattrs that are in the
> NFSv4 standard.

You are right, it was also mentioned in the latest proposal.  But support
for Linux attributes may easily coexist with support for NFSv4 extended
attributes in GNU tar in future - they should never interfere.

>> Paul, Sergey, Linux extended attributes are quite important file system
>> feature -- at least users of POSIX ACLs, capabilities or SELinux need
>> some way to backup these.  I'd be glad to help you with related
>> problems to reduce maintenance cost of course if you reconsidered
>> patching GNU tar for xattrs again.  Could you discuss the pros and cons
>> in mentioned thread?
> There is nothing named "POSIX ACLs".
> The only ACL standard I am aware of is the ACL system that is part of the 
> NFSv4
> standard, which is identical to NTFS ACLs.
> 20 years ago, there was a POSIX draft for ACLs that was implemented by some
> UNIX systems such as Solaris, SCO and IRIX. This draft has however been
> withdrawn 15 years ago already. 4 years later, Linux started to implement this
> withdrawn draft.

Sure, I should say "abandoned POSIX.1e ACLs" to be fully specific, sorry
for this.  But the importance of this feature stays the same regardless of
POSIX.1e draft status -- ACLs are widely implemented and it is important
to have possibility to backup them.  Yep, everybody can (to be honest -
has to) switch to star/bsdtar ATM when he needs store/extract *complete*
file with its attributes.

> star supports these deprecated ACLs since 2001. You definitely do not need
> support for Linux xattrs for ACLs as this is an implementation detail.

Of course, I erroneously talked about whole proposal (5 patches).

POSIX.1e ACLs separated patch may be accepted/dropped independently of the
extended attributes or SELinux because all of them are using special APIs.

But even the support for *RAW* extended attributes only may help to wide
range of GNU tar users because these ACLs and SELinux are now often
implemented as extended attributes.  Proposed patches allows also this
kind of work-flow.


The reason why Fedora ships xattr-patched GNU tar is because it is really
needed AND because we don't want to do the s/gtar/star/ or s/gtar/bsdtar/
substitution for our default tape archiver.  It seems that other
distributions are (were) facing similar problem.

Paul or Sergey, could anybody from you look at proposed patches?  If you
had already reviewed it, could you tell why you decided to drop this?  It
may have flies of course but I'm able to cooperate with you to fix them.

Thanks again,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]