1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
The following is a list of things I would like to see
done with libarchive. It's sorted roughly in priority;
more feasible and more often-requested items are higher
on the list. If you think you have time to work on any
of these, please let me know.
* More compression options: Recent improvements to the
read bidding system and external program support should
make it very simple to add support for lzo, lzf, and
many other command-line decompression programs.
I've even written up a Wiki page describing how to
do this.
* cpio front-end. The basic bsdcpio front-end is now
working. I'm looking for feedback about what additional
features are necessary.
* pax front-end. Once cpio is a little more stable, I plan
to fork it as the basis of a pax front-end. The only really
tricky part will be implementing the header-editing features
from POSIX 2001 'pax', which will require some changes to
the libarchive API.
* libarchive on Windows. libarchive mostly builds cleanly
on Windows and Visual Studio. Making this really clean
requires reworking the public API to not use dev/ino; I
think I know how to do this but could use advice from
someone knowledgable about Windows file-management APIs.
* Linux large-file/small-file dance. libarchive always
builds with 64-bit off_t and stat structures; client programs
don't always do this. Supporting client programs built
with 32-bit off_t requires a little trickery. I know how
to do this but haven't had time to work through it.
* bsdtar on Windows. After libarchive is working on Windows,
this should be much simpler. At worst, you can just disable
features.
* Writing tar sparse entries. The GNU "1.0" sparse format
sucks a lot less than the old GNU sparse format, so I'm finally
dropping my objections to sparse file writing. This requires
extending archive_entry to support a block list, and will
require extensive changes to bsdtar to generate block lists.
The sparse read code will also need to put block lists into
the entry so that archive-to-archive copies preserve sparseness.
* ISO9660 writing. Writing ISO9660 requires two passes, and
libarchive is a single-pass API. For ISO9660, you can hide
that behind a temp file, though. Collect metadata in memory,
append file bodies (properly padded to 2k sector boundaries)
to a temp file, then format the directory section and copy
the file data through at format close.
* archive_read_disk: Currently, libarchive can generate a stream
of entries from an archive file and can feed entries to an
archive file or a directory. The missing corner is pulling
entries from a directory. With that, libarchive can provide
efficient bulk copy services for dir-to-dir, dir-to-archive,
archive-to-dir, and archive-to-archive. Right now, the
read-from-disk capabilities are handled in the client.
* ISO9660 Level 3. ISO9660 Level 3 supports files over 4GB.
* --split=<limit> option to bsdtar. This would watch the total output
size and begin a new archive file whenever <next file size> +
<total archive size> exceeded <limit>. Not as robust as
GNU tar's ability to split an entry across archives, but still
useful in many situations.
* Filename matching extensions: ^ to anchor a pattern to the
beginning of the file, [!...] negated character classes, etc.
|
