pax_restricted and SCHILY attributes

42 views
Skip to first unread message

olly

unread,
Aug 15, 2010, 9:28:49 AM8/15/10
to libarchive-discuss
Hi,

I'm converting some code to use libarchive because I need to build tar
files with stupidly long pathnames in them and the original homegrown
ustar implementation can't do pax. So instead of hack it, I'm
migrating to your excellent library instead. Thanks for that :-)

My issue is this. I'm choosing to use pax_restricted because I want
maximum tar compatability, but when it is forced into pax extensions
by the long paths it also by default adds SCHILY.dev, SCHILY.inode and
SCHILY.nlink. As I'm generating a tar file containing data extracted
from a database, these attributes have no real meaning and their
presence causes gnu tar (at least the old version we need to support)
to issue errors about unsupported attributes and fail. This is no
good for me.

I'm proposing two changes that I could contribute to the code that
would help fix this situation. I'm happy to code and submit either;
just want people's opinions as to which one is more appropriate:

1. modify the pax_restricted mode so that it doesn't generate these
three attributes; it will still generate extended attributes for any
parameters that extend beyond ustar capabilities, but will not include
these three by default.

2. add an option to the pax_restricted mode called something like "no-
SCHILY" which suppresses the generation of the SCHILY attributes if
present.

Thoughts?
Thanks,
Olly

PS> I'm currently using 2.8.4; it occurs to me whilst writing this
that I haven't checked 'trunk' to see if the behaviour has changed at
all; I'll do that when I get a chance.

Tim Kientzle

unread,
Aug 15, 2010, 3:00:15 PM8/15/10
to libarchiv...@googlegroups.com
Personally, I try to avoid adding more options when there's
a reasonable alternative.

In this case, I think it makes a lot of sense to not include
those attributes in pax_restricted archives.

If you need any pointers putting together the patch, let
us know.

Cheers,

Tim

> --
> You received this message because you are subscribed to the Google Groups "libarchive-discuss" group.
> To post to this group, send email to libarchiv...@googlegroups.com.
> To unsubscribe from this group, send email to libarchive-disc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/libarchive-discuss?hl=en.
>

olly

unread,
Aug 15, 2010, 5:26:31 PM8/15/10
to libarchive-discuss
Tim Kientzle wrote:
>
> In this case, I think it makes a lot of sense to not include
> those attributes in pax_restricted archives.

Excellent; that's a simpler patch.
I'll put something together when I'm back in the office later this
week.
Do I post patches here?

Olly

Tim Kientzle

unread,
Aug 15, 2010, 6:27:47 PM8/15/10
to libarchiv...@googlegroups.com

Yes.

Tim

Joerg Sonnenberger

unread,
Aug 15, 2010, 6:35:46 PM8/15/10
to libarchiv...@googlegroups.com
On Sun, Aug 15, 2010 at 9:00 PM, Tim Kientzle <t...@kientzle.com> wrote:
> Personally, I try to avoid adding more options when there's
> a reasonable alternative.
>
> In this case, I think it makes a lot of sense to not include
> those attributes in pax_restricted archives.

I don't see a reason to include those fields at all. I would just drop them.

Joerg

Tim Kientzle

unread,
Aug 15, 2010, 8:50:39 PM8/15/10
to libarchiv...@googlegroups.com

That would be even simpler.

Tim

olly

unread,
Aug 19, 2010, 4:55:39 AM8/19/10
to libarchive-discuss
Well, here's the patch that suppresses them in restricted mode.
If you choose to just drop them instead that's fine with me as I get
the same end result :-)
Olly

Index: libarchive/archive_write_set_format_pax.c
===================================================================
--- libarchive/archive_write_set_format_pax.c (revision 2554)
+++ libarchive/archive_write_set_format_pax.c (working copy)
@@ -956,12 +956,16 @@
/* Include star-compatible metadata info. */
/* Note: "SCHILY.dev{major,minor}" are NOT the
* major/minor portions of "SCHILY.dev". */
- add_pax_attr_int(&(pax->pax_header), "SCHILY.dev",
- archive_entry_dev(entry_main));
- add_pax_attr_int(&(pax->pax_header), "SCHILY.ino",
- archive_entry_ino64(entry_main));
- add_pax_attr_int(&(pax->pax_header), "SCHILY.nlink",
- archive_entry_nlink(entry_main));
+ /* Note: in pax_restricted mode, we omit these
+ * as we're aiming for maximum tar compatibility. */
+ if (a->archive.archive_format ==
ARCHIVE_FORMAT_TAR_PAX_INTERCHANGE) {
+ add_pax_attr_int(&(pax->pax_header),
"SCHILY.dev",
+ archive_entry_dev(entry_main));
+ add_pax_attr_int(&(pax->pax_header),
"SCHILY.ino",
+ archive_entry_ino64(entry_main));
+ add_pax_attr_int(&(pax->pax_header),
"SCHILY.nlink",
+ archive_entry_nlink(entry_main));
+ }

/* We use GNU-tar-compatible sparse attributes. */
if (sparse_count > 0) {

Tim Kientzle

unread,
Aug 22, 2010, 4:36:09 PM8/22/10
to libarchiv...@googlegroups.com
On Aug 19, 2010, at 1:55 AM, olly wrote:
> Well, here's the patch that suppresses them in restricted mode.
> If you choose to just drop them instead that's fine with me as I get
> the same end result :-)
> Olly

I committed r2563 that just drops these from libarchive/trunk. (I've not gotten any
feedback from anyone who actually uses these and they seem to
just be causing problems.)

Note: If your primary concern is interoperability with gnutar, you
might also consider the basic gnutar format writer that's now
in libarchive/trunk. It's not very complete but it does handle
long filenames and long linknames.

Cheers,

Tim

Reply all
Reply to author
Forward
0 new messages