[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