commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: [compress] Discussing compress
Date Tue, 14 Feb 2006 15:41:20 GMT
Hi!
> Can you explain a bit more, why i should use streams only in public
> instead of a byte-manipulation like with RandomAccessFile. Any link or
> comment here is appreciated.
I just thought it is not possible to change a archive that way.
While I can image that it might work to add a file ...
How do you change a file?
How do you delete a file and shrink the archive?

And all this heavily depends on the used compression type. So you might
have to implement this for zip/jar/tar - ok - I know tar is not a
compressed archive - but its a archive where it might be nice to have
write support for.

> I found out that i possibly can use RandomAccessFile and read byte for
> byte and write in back to the same file at the same time.
Sure, but you have to write a compressed stream.

> This may lead to a corruption of the source file when the operation is
> interrupted, but is fastest.
This is bad, isnt it?

> I could read the file as a stream and write the needed bytes as
> output-stream in another temp-file which has to be mv'd to the source
> after finished. That would be fast and quite secure. But i need a
> tempfolder where something can get wrong.
>
> The issue with decompressing to a temp-folder and compressing it again:
> I think it would be faster if i could manipulate the bytes directly.
> And what if the temp-folder is beeing manipulated while the operation
> runs? What if the zipfile is huge so space in the temp-folder runs out?
throw new IOException() ;-)

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message