[Top][All Lists]

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

Re: [Bug-tar] Re: [PATCH] Extended attribute support for tar

From: Sergey Poznyakoff
Subject: Re: [Bug-tar] Re: [PATCH] Extended attribute support for tar
Date: Wed, 02 Aug 2006 21:50:08 +0300

James Antill <address@hidden> wrote:

> > 1. All xattrs-specific stuff should be concentrated in one source module
> >    instead of being scattered around 7 source files;
>  I can see why you'd want this for some of the code (xheader_xattr_* for
> example) ... but, for instance, I'd assume that the code in
> start_header() and options processing in tar.c should stay where it is?

Yes, what I meant is that the parts of code fiddling with xattrs on the
low level should go to a single compilation unit, so that they could
easily be disabled on systems lacking the necessary support.

> > 3. I don't see any reason to create a second (prefix) table in
> >    xheader.c, I'd prefer to expand the functionality of the main table
> >    instead;
>  I can combine the tables with a "is_prefix" type member, I'm not sure
> this is better though. As the code should probably still run through the
> table twice in lookup (one for a direct match and once for prefix
> matches), and ignore the prefix entries in the other functions.

Not necessarily. I guess it can be achieved in one go.

> > > 7. Currently tar defaults to not doing anything when creating an
> > > archive, so you need to pass --xattrs or --selinux to get all xattrs or
> > > just SELinux context information in the archive.
> > 
> > That's OK as well.
>  Would it be ok to have one or both of these on by default, at some
> point in the future?

No, I believe this would be superfluous. If the user wants it, he will
turn it on.
> > It should be limited to POSIX.1-2001 format only (POSIX_FORMAT). 
>  This would mean the default would have to change when you enable that
> option[1],

There are two possibilities: either --xattrs implies -Hposix, or it is
a no-op unless -Hposix is given. I prefer the former.

> is there a reason to not allow it with the gnu format?

Yes, there is: GNU format knows nothing about POSIX extended headers,
where xattrs are stored (they could possibly be stored in some new kind
of headers, but I do not want to further expand GNU format, given that
it has created enough problems already and that POSIX format is far
superior by design). 

> Also to be compatible[2] with star we need to at least extract from ustar
> typed archives (star's exustar is treated by GNUtar as ustar ... AIUI).

No, if it contains extended headers, it is a POSIX archive (more
properly - POSIX.1-2001). Ustar (or POSIX.1-1988) archives 
can not contain them.
>  What are the downsides to changing the default to be posix -- which is
> basically what would be happening as xattr usage is leaking into more
> and more applications. The documentation says that this is planned when
> full support for posix archives is done, is this close to happening?

Actually, it is already done. As for changing the default, this will
require certain time, of course.

reply via email to

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