[
https://issues.apache.org/jira/browse/COMPRESS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bear Giles updated COMPRESS-132:
--------------------------------
Attachment: test-z.dump
test.dump
dump-20110722.zip
Attached is latest snapshot. It contains a unit test and two sample files. The
sample files (which are identical except for compression) contain various
special files, SELinux labels and one user-defined attribute. XA is recognized
but ignored.
There's a POSIXArchiveEntry class but it hasn't been synced with recent changes
in the commons library.
Since there isn't a lot of code it could be made consistent with 1.4 if desired.
On output streams - I have been giving a lot of thought since the archives
aren't simple streams. I can skim the extra information in the input stream
since it only affects internal state. I can't do that on the output stream
because some of the header information is exactly sized to the amount of data
that will be archived - you can't keep adding to it like a tar or zip file.
(Unless you're willing to cache everything, of course.) I haven't given up on
this approach yet but it's a non-trivial problem.
The other issue is getting some of the gory details that aren't available in
the standard java.io.* classes. The cleanest way is using JNA to bind to
libc... but that introduces dependencies on JNA.
> Add support for unix dump files
> -------------------------------
>
> Key: COMPRESS-132
> URL: https://issues.apache.org/jira/browse/COMPRESS-132
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
> Reporter: Bear Giles
> Priority: Minor
> Fix For: 1.3
>
> Attachments: dump-20110722.zip, dump.zip, test-z.dump, test.dump
>
>
> I'm submitting a series of patches to the ext2/3/4 dump utility and noticed
> that the commons-compress library doesn't have an archiver for it. It's as
> old as tar and fills a similar niche but the later has become much more
> widely used. Dump includes support for sparse files, extended attributes, mac
> os finder, SELinux labels (I think), and more. Incremental dumps can capture
> that files have been deleted.
> I should have initial support for a decoder this weekend. I can read the
> directory entries and inode information (file permissions, etc.) but need a
> bit more work on extracting the content as an InputStream.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
