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