Re: CPIO archives

True, memory is a problem. The best would be your suggestion to select
temporary saving of the cpio informations to the file system by a
special method. If the method is selected we could write the file
to the FS otherwise we hold them in memory. Reading should occur
from a input stream so that we could read rpms from a url in one
step. The threshold can be implemented later.
How does the ZipInput/OutputStream in java.util.zip handle this problem?
Maybe we should handle CPIOs the same way? Maybe it would be a good
idea to move cpio to an extra package so that we can provide cpio as
an extra java api.

Also we should include bzip2 support. I have seen this implemented at
jakarta but now it had moved somewhere but I do not know where to find
the api now.

Btw. have you seen the activity percentile back on sf.net?
No more 0 :)


Yannick Menager wrote:
> Also please note that it won't write to the filesystem if the rpm that 
> is being read is constructed from a File..
> 
> It's only in the case of using only an inputstream where he will do so.
> 
> some thoughts about this:
> 
> - We could have an "read and extract immediately" function, which would 
> use same inputstream without saving to disk.
> 
> - We could allow to set a "treshold" size, where it would keep it in 
> memory if smaller than that size, or use disk if bigger.
> 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/