On Tue, 14 Jun 2011, Antoni Mylka wrote:
But the ZipContainerDetector works by looking for the existence of certain entries with known names and in certain cases it reads the content of those entries (e.g. "[Content_Types].xml"). If those entries happen to live at the beginning of the file then you can detect the type by giving the detector a fixed header (of say 512KB).

They often won't be at the start of the file, so I would advise against this as a strategy...

The only drawback is the necessity to create the temp file from this small header. If you're already do lots of filesystem activity in your app (crawling the files and generating an index), especially on a desktop machine with a single non-SSD disk, then every fs operation you don't make, allows the fs cache and disk head to do more stuff in other places. Yet the profits will likely be small, and the cost of rewriting the ZipContainerDetector seems large.

I've a feeling that changing the code to work with either a file or a stream isn't too much work with commons compress. Can you open a jira enhancement for this? And if you want to work on it, great! Otherwise I'll take a look when I can.

Nick

Reply via email to