[some long time ago...]
On Wed, Sep 09, 2009 at 04:42:01PM +0200, Florian Festi wrote:
> A much simpler alternative would be to use a slightly modified cpio
> format. With a new magic for large files we could just put an binary
> integer into the c_filesize field (or all integer fields). Another
> solution could be to keep the hexadecimal encoding and just double the
> c_filesize or even some more integer fields.
> This will both render the payload incompatible with cpio if there are
> large files (and only then).
Why does it need to be incompatible? How about saving oversized files
in multiple parts. All but the last part would have size 0xffffffff.
E.g. /tmp/longfile would be archived as:
- cpio header size = 0xffffffff name=/tmp/longfile
- cpio header size = 0x123 name=/tmp/longfile.part2
When rpm's cpio unpack sees a file with size 0xffffffff it knows
that it is just a part and skips the next cpio header + filename.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
