Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <2551.131.207.166.197.1152079864.squirrel@webmail.zeniitti.net>
Date: Wed, 5 Jul 2006 09:11:04 +0300 (EEST)
Subject: [vfs] Enchancing extraction
From: "hrjk" <harrik@zeniitti.net>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Reply-To: harrik@zeniitti.net
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

Hi.

I was wondering if you've planned to enchance extraction process of VFS? I
know, that extracting packages isn't the main driver behind developing VFS
library. However, VFS works unlike Java.util.zip (the umlaut issues) and
can handle several file types.

We've been using VFS, and with small zip packages (less entries)
extraction is efficient. However, when the package size (and entry count)
increases, the extraction time is increased almost exponentially. For
example, one large (>1Gb) zip took 7 minutes with org.apache.tools.zip and
1:07 minutes with VFS. So over 1 hour more... This is a huge issue for us
atleast.

So basicly I was wondering if it would be possible to change VFS to easily
"skip" the caching process when resolving file, but merely request next
entry from zip or any other file. I think this would help the efficiency
issues, or am I missing something? What do you think of this?

BR,
hrjk


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org