> For tar it would be one block (usualy 512 bytes), for zip the full > central directory has to be read which could be quite a bit. >
Urgh. Because that's at the end for zips? That's not so good then. > > I currently plan to implement it inside getNextEntry as it is cleaner. > In the tar case I vaguely recall some implementation only write one EOF > marker so a more careful aproach is needed in order to not read beyond > the end of the archive (likely mark and reset if the stream supports > mark). > Hm. That suddenly makes (2) much interesting again. I can see the back and forth on this :)
