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.
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.
Created attachment 109758 [details] 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.
(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.
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?
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 ...
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: better allow user to extract/save a zip file on the fly in download → extract .zip files "on the fly" during download
How about putting bugs in the right component when you confirm, eh?
Assignee: blaker → law
Component: Download Manager → File Handling
Priority: -- → P5
Target Milestone: --- → Future
Rumor has it Safari extracts .zip and .dmg for you.
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...
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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
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?
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 :).
[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.
Hardware: PC → All
Whiteboard: p-safari → [sg:want P4] [p-safari]
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.
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
(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).
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.