On Tue, Mar 30, 2010 at 09:36:09AM +0300, Panu Matilainen wrote:
> On Mon, 29 Mar 2010, FlorianFesti wrote:
>
> >On 03/26/2010 05:01 PM, Michael Schroeder wrote:
> >>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
> >May be this is just a bit too obvious...
> >
> >First disadvantage I can think of is that "rpm2cpio | cpio" will no longer
> >produce the file contents correctly.
>
> Yup, which kinda misses the point IMO: its incompatible anyway, only in a
> somewhat different way. At which point it might as well be done with a new
> format that actually supports the large sizes cleanly, and probably by
> only using the large-file format when actually necessary to avoid
> unnecessary incompatibilities with 99.9% of the packages out there.
The advantage of the multipart way is that you can still extract all of the
< 4GByte files. And you have the chance to recreate the > 4Gbyte files
by doing a simple 'cat'.
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
