175008 - extract .zip files "on the fly" during download

Status: REOPENED

(Firefox :: File Handling, enhancement, P5)

Description

[Wenqing Jiang]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021017
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021017

This is an enhancement sugguestion, not a bug.  I searched the
bugzilla for "extract zip", "download unzip" and found nothing.
Hope this is not a dup that just wastes your time.  (but if it
is, please tell me how I can do better next time.  - thanks)

When downloading a zip file, to options are available - either
save the zip file to disk, or open it using the associated tool
(such as winzip).  The second option is done be saving the zip
to a temp file and hands it to the zip tool.  The zip file is
usually unzipped later.

Hope mozilla can provide a third option of "extract and save
to ...".  I'm not sure if zip format is a "flow" format that
can be extracted as a stream without having to look at the
whole file first.  To my knowledge, the zip file has a file
directory at its end, but in the stream each file has a copy
of its header, so maybe extract on-the-fly can be done.

If so, we can have some savings: only the content of the zip
is written to the disk, saving disk IO.  The present options
requires much IO and disk space: save zip to disk, read the
zip to extract, write the extracted to disk (2 writes, 1 read).
extract on-the-fly would have only 1 write.

Same to .gz, .tar and .tar.gz files.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[http://tinymailto.com/oliversl]

When you select "Open", Mozilla calls the default .zip application handler.
Is that what you want?
You can also select "Open With ..." to choose a diferent program to open.

Comment 2

[Wenqing Jiang]

Attachment: download and extract .zip files on-the-fly

The java program will download and unzip a zip file in URL on-the-fly,
no temp files saved to local.
useage:
<java1.3 dir>/java.exe -classpath <path> NetUnzip <URL>
where <path> is the dir holding compiled NetUnzip.class.

cd \mozilla
rd /s /q bin
java -classpath c:\myJava NetUnzip
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip

will extract the latest mozilla directly to current directory.
- That's the way I updated my mozilla every day.

Comment 3

[Wenqing Jiang]

(see attachement #109758)

When clicking on a .zip link in mozilla, you can chose to save the zip file
or open it with a zip utility (like winzip).  In both cases the zip file
will be saved to local (either in original name or as a temp file).

What I suggested is a third option: not to save to zip, but download and extract
on-the-fly.  Please look at the attachment.  It's a java program that does what
I suggested.

To my knowledge, mozilla has inflate algorithm code in it so it can be reused
to do this.

Comment 4

[http://tinymailto.com/oliversl]

What will happend if the zip file has:
- a comment
- a password
- many directories and sub-directories

I don't see why this should be implemented. Only to save disk space?

Comment 5

[Wenqing Jiang]

Comments won't be extracted - even you save the zip file and then extract it.  So
comments should not be a problem.

If the zip file has a password, users can be prompted for it, or they can change
their minds and choose to save the zip file.

The directory and subdirectories are restored on-the-fly.  See the .java file
for this.  You can test it after you compile it.

The saving should be disk space plus time.  If save and unzip:
1) download
2) save .zip file (disk write)
3) winzip read .zip file (disk read)
4) extract
5) save extracted file (disk write)

If unzip can be pipelined with download, then steps 2, 3 will be omitted.

Of course this feature is not nececity.  It's just an enhancement suggestion.
You've already the source code for download and for unzip (inflate), so
if you finally decided to implement this you needn't write from zero ...

Comment 6

[Jesse Ruderman]

Fixing this bug would:
* Eliminate the extra UI I have to go through to unzip a file (open the zip
file, tell it where to unzip to, close the unzipping-related windows, delete the
zip file) after downloading it.
* Combine two steps during which I have to wait for a long time (downloading and
unzipping), reducing the total amount of time I have to wait by up to 50%.

There's a similar bug for mail attachments, bug 180798.  Note that for mail
attachments, you already have the whole zip file when you start unzipping, so
the code can be simpler.

Doesn't seem to be a dup (used bugzilla quicksearch: 'sav,download
zip,extract,compress'), so confirming.

Comment 7

[Boris Zbarsky [:bzbarsky]]

How about putting bugs in the right component when you confirm, eh?

Comment 8

[Jesse Ruderman]

Rumor has it Safari extracts .zip and .dmg for you.

Comment 9

[Wenqing Jiang]

After some thought I propose to drop this feature/enhancement, and also
drop the similar one in mail.  The reason is the following difficulties
if we do try to implement it:

1) zip file may be password protected, and each file within the zip file
   can have different passwords;
2) the latest zip file format suports 128-bit, 256-bit AES encryption in
   addition to the traditional encryption, making extract on-the-fly
   more difficult;
3) zip file may be corrupt, and how to handle this may trigger a miriad
   of problems
4) you can usually estimate needed disk space when downloading a file,
   but not so when you extract a zip file directly to disk.  Handling
   out-of-disk problem may be very complex when you're in the middle of
   unzipping.

So, why not let the browser do its share of work well, and leave the zip
to others?  As a reporter I'd say unzip-on-the-fly is not a good proposal...

Comment 10

[Wenqing Jiang]

The "unzip on the fly" is something that falls out of the
responsibilities of a browser.  So to keep the browser
simple and efficient, I'm dropping this feature request.

Thanks you for all the discussions.

Comment 11

[Jesse Ruderman]

I still think this is a good idea.  See comment 6 and comment 8.

Comment 12

[http://tinymailto.com/oliversl]

I think its a good idea but its too complicate.
I think most users have been dealing with .zip files all this years, they know
that they are and in windows XP you can just doble click on them.

See comment #9 and comment #10

Maybe you can make an extension, and if it is too popular, it can be shipped 
with the next Firefox release.

Think about virus in a .zip file. What to do with .rar, custom .zip formats,
etc, etc.

If the developer just closed the bug, I think it should stay closed. Happen 
before and is the way it works.

Regards

Comment 13

[Wenqing Jiang]

I agree with comment #12.  It's just complicated to implement the feature
with so many ramifications.  Jesse, do you have any ideas on how to cope
with the issues in comment #9?

Comment 14

[timeless]

fwiw i just grabbed a .sit this morning, and safari did not extract it for me,
perhaps some older version did, and apple stopped once they got bitten by an
autorun attack :).

Comment 15

[Jesse Ruderman]

[sg:want P4] - Handling zip files would have the some security benefits:

* It would be possible to warn when a compressed download contains an application.  Both Windows Explorer and Mac's Finder make it difficult to tell the difference between an application (which will launch when double-clicked) and a data file, so it would be good to help users out with compressed files as well as simple downloads.  See also bug 249951.

* It will allow users to avoid the unpredictable behavior of the "Extract here" command in most unzipping programs.  Using "Extract here" on some zips places a bunch of files in the download directory.  If your download directory is the desktop and you don't realize that the zip placed an extra "Firefox" shortcut on your desktop when you unzipped it, you might click on the malicious shortcut later.

Comment 16

[legolas558]

Absolutely to be dropped.

This would contribute to making Firefox a browser with "whistle and bells". I would prefer a browser doing well one thing, browsing the web.

It is more suitable for an extension.

Comment 18

[legolas558]

(In reply to comment #16)
> Absolutely to be dropped.
> 
> This would contribute to making Firefox a browser with "whistle and bells". I
> would prefer a browser doing well one thing, browsing the web.
> 
> It is more suitable for an extension.

Well, after a couple of years I have changed my mind: I vote for including this feature because we are definitively in the age of pro-active applications and - sooner or later - there will be some browser (Opera?) implementing this because it is on the path of natural software evolution (IMHO).