commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Grobmeier" <grobme...@possessed.de>
Subject Re: [compress] Discussing compress
Date Tue, 14 Feb 2006 15:04:09 GMT

> but be sure to
> only work with streams in your public API. So you might have to
> decompress and recompress the archive in a local temp folder to make
> those operations work.
> 
> I think in your local temp directory you should NOT use the original
> filenames of the archive as they might contain invalid characters for
> the current filesystem. So it might be best to generate dummy names and
> maintain a map of those to their real names.
> 

I was thinking about that problem before a while.
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 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. This may lead 
to a corruption of the source file when the operation is interrupted, 
but is fastest.

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?

Regards and thanks,
Chris	



---------------------------------------------------------------------
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