Re: [AVFS] internal uzip.c broken for zips with many entries

Hi,

On 2014-06-09 22:23, Dan Muresan wrote:
> Ubuntu 14.04 here, avfs == 1.0.1-2:amd64. The internal uzip.c handler
> seems broken for zips with many files:
> 
> # hint: use a tmpfs working directory for faster tests
> tst$ find . -delete
> tst$ perl -wle 'for (1..50000) { mkdir "$_$_"; open (my $f, ">",
> "$_$_/$_"); close $f; }'
> tst$ mountavfs
> ls ~/.avfs/tmp/x.zip#
> ls: cannot access /home/user/.avfs/tmp/x.zip#: No such file or directory
> 
> A strace shows
> 30384 sendto(5, "<14>Jun  9 21:22:01 avfs[26671]: UZIP: Broken
> archive", 53, MSG_NOSIGNAL, NULL, 0) = 53
> 
> With x.zip#ext-uzip (on Ubuntu) it works. Also, for fewer zip entries
> (e.g. 1..10000) the internal handler works too

thanks for the report. I can reproduce it and will look into that.

> BTW, what is the performance impact of using the external handler? I
> really need to transparently mount archives, and need an archive
> format with a central entry table for fast random access (zip and rar
> are the most obvious choices I guess).

For the external handler, every single file is extracted separately from
each other which often introduces a significant performance penalty,
especially if the extracting tool cannot randomly access files inside
the archive. The internal handlers try to avoid that by storing seek
offsets for fast random access.

Best Regards,

Ralf Hoffmann

-- 
Ralf Hoffmann <[email protected]>
Homepage: http://www.boomerangsworld.de

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems