Open GoogleCodeExporter opened 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
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
Original issue reported on code.google.com by
joerg.sonnenberger@googlemail.com
on 16 Mar 2010 at 7:22