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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
