[
https://issues.apache.org/jira/browse/COMPRESS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086124#comment-13086124
]
Stefan Bodewig commented on COMPRESS-132:
-----------------------------------------
I've managed to create archives and committed an initial testcase which fails
to extract the files (they are empty), I'll try to investigate whether this is
due to changes I have made or already happens with your code base later.
The other thing that fails is format recognition. The archives I have created
contain the magic number 60012 at offset 24 (where my magic file expects it to
be) but the code in the matches method is looking at offset 7. Is the code
wrong?
Also, do you think we'd need to also check for little endian order or the
old-fs dump (60011) or does the current code not support those anyway?
> 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
