173615 - Libjar changes to extract the number of files per archive (harness total_entries_archive)

Status: RESOLVED WONTFIX

(Core :: Networking: JAR, defect)

Description

[[e-mail] (away - not reading bugmail)]

We have a new requirement to provide more frequent progress updates, please
refer to bug 168139. See bug 81144 for the UI issues to be addressed when this
has been implemented.

Comment 1

[[e-mail] (away - not reading bugmail)]

Adding feedback solicited via private email exchange with sgehani and dveditz:

-----

No visible objection.  It appears to be mentioned in the appnote [1]. I'd dump
(e.g., od -x) archives created by several ``leading'' zip tools including
Cygwin's zip, PKZip, WinZip, Sun's jar, et. al. and examine for the existence of
this field.
~Samir 

-----

The number of items in the archive is roughly the same as the number of
install steps but usually won't match exactly. A simple archive might have
fewer steps than files (some like install.js or directory entries are
overhead, some might be conditionally installed). Most will probably have
more steps than files (registry entries, shortcut creation, chrome
registration, etc).

If you've got one long bar that you're progressing along it'll work great as
long as you hold at the local expected max for each archive when it goes
over a little bit, or jump to catch up at the next stage in the rare case of
having fewer.

The jumps or pauses might be more noticeable if you go a full 0-100% for
each archive.

-Dan Veditz

Comment 2

[[e-mail] (away - not reading bugmail)]

Attachment: preliminary (functional) patch

The patch seems to be working very well, although "total number of entries in
the central directory" seems to include files *and* directories. I'll have to
rename 
the helper functions accordingly. Perhaps "GetItemCount" would be more fitting.


The following is an excerpt from browser.xpi with two directory entries and
three files; GetItemCount == 5 in this case.

Archive:  browser.xpi
  Length     Date   Time    Name
 --------    ----   ----    ----
	0  11-25-02 12:10   bin/
	0  11-25-02 12:10   bin/chrome/
   275673  11-20-02 12:42   bin/chrome/chromelist.txt
   299381  11-19-02 00:44   bin/chrome/classic.jar
   924765  11-21-02 15:49   bin/chrome/comm.jar


Sean, thanks for pointing me to the right direction!

Comment 3

[Sean Su]

over to me

Comment 4

[[e-mail] (away - not reading bugmail)]

Sean,

I had a working build with this patch in it, it worked quite well. Let me know,
if you needed it for evaluation purposes.

Comment 5

[Alfred Kayser]

Attachment: ZIP_GetFileCount to get count from a closed zipfile

Looking at the patch, I noticed this:
+  if((ZIP_OpenArchive(szArchive, &vZip)) == ZIP_OK)
+  {
+    /* 1st parameter should be NULL or it will fail */
+    /* It indicates extract the entire archive */
+    iFileCount = ZIP_GetFileCount(vZip);
+    ZIP_CloseArchive(&vZip);

OpenArchive is 'slow' as it reads the full zip index, and builds
an hash table for it.

Beter would be to create a separate ZIP_GetFileCount(const char * filename),
to get the item/file count from a 'closed' zip.

Comment 6

[Alfred Kayser]

I've got a patch ready to include a 'ZIP_GetItemCount' function to
nsZipArchive, without the Open/Close overhead.
Will upload it soon.

Comment 7

[Alfred Kayser]

Any volunteer to compile and test this patch?

Comment 8

[Caleb]

Does this depend on bug 214672?

Comment 9

[Alfred Kayser]

=> Does this depend on bug 214672?
No, they are not related at all.
´ZIP_GetFileCount' (second attachment) can very easily be added to the current
codebase.

Comment 10

[Alfred Kayser]

Any one still interested in this?
4 years of silence means this probably not interesting?