pombreda / libarchive

Automatically exported from code.google.com/p/libarchive
Other
0 stars 0 forks source link

Allow explicit format specification for bsdtar -x #80

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
It should be possible to explicitly say "this is a mtree spec" or even
"this is a raw" file for bsdtar, disabling the normal bidding once the
input files are done.

Original issue reported on code.google.com by joerg.sonnenberger@googlemail.com on 16 Mar 2010 at 7:22

GoogleCodeExporter commented 9 years ago
The same applies for other cases where an archive is read -- @foo.mtree comes 
to mind.

Original comment by joerg.sonnenberger@googlemail.com on 24 Mar 2010 at 9:33

GoogleCodeExporter commented 9 years ago
There are a couple of pieces here.

1) Within libarchive, I've long wanted to split out 
archive_read_support_format_XXX()
and archive_read_set_format_XXX().  Ideally, the second of these would be 
identical
to the current init() methods called for the winning bidder.  This is actually 
on the
WishList Wiki page already.

2) Once that's in place, --format= can call read_set_format() to set the format
explicitly, bypassing the bidding.

3) For the @foo.mtree case, we need some additional syntax to specify the 
format.  A
command-line option is one possibility, keying from the filename is another, we 
could
also extend the syntax to something like @{mtree}foo.bar.

One big motivator here is, of course, the mtree format.  I'm not happy about
requiring a magic initial line, because it makes it hard to do Unix-like things 
such as
  $ find . -mtree | grep Makefile | sed 's/root/nonroot/' | tar cf file.tar @-
I would like to look for ways to auto-detect mtree without requiring the magic 
line,
but I expect that some way to explicitly provide a format hint might be 
required in
some cases.

The other motivator is handling slightly-damaged files.  The bidders are 
necessarily
rather strict, so we want a way to coerce the format so that people can use
bsdtar/bsdcpio with files that are damaged enough to fail the bid but still 
recoverable.

Of course, the next obvious step is to extend similar capabilities to the 
filters. 
The command-line interface could be tricky; I expect we should use strings that 
look
similar to file extensions to specify the full transform and archive format, 
e.g.,
"tar.gz.uu".

Original comment by kientzle@gmail.com on 25 Mar 2010 at 4:44