unable to open Firefox 4.0 omni.jar

Several unzip tools and archives (including 7-Zip) currently cannot read omni.jar, due to the optimization that is applied to the file.

Can this be fixed in 7-zip?

Hello everyone,

o…k… What's wrong with this? I just tried with 7-Zip 9.20 (0.2 to be honest) and it opened fine (omni.jar from 05. Nov 2010).

Best regards!

I tried 9.20.02, didn't work.

xp sp3, 7-zip 9.20 or 9.20.02, Fx 4.0b7

"Can not open file '…\omni.jar' as archive"

Read my posts about omni.jar here:
http://sourceforge.net/tracker/?func=detail&aid=3065694&group_id=14481&atid=114481

The fix is only 2 lines in 7-zip code, but I'm still not sure that it's good thing to use that fix.

I've read the comments.  So the bottom line is: it doesn't look like mozilla will revert to the original layout and Fx4 with ship with the new one.   From the users' perspective it is definitely a good thing to support.  Unless the fix in some way degrades the support for more strictly standard adhering files, why not?

Did you see any benchmarks that show that there is any gain with new layout?
Maybe FireFox developers don't understand for 100% what they are doing.
They break original ZIP standard.

Can you look at it this way:  lets say they don't know what they're doing, lets say that this is an invalid/broken zip file, or call it a new mozilla derivative file format.  Still, it would be really helpful if 7-zip could open it, especially considering that the native windows zip viewer can do it (if you rename the jar to zip) and also how easy it would be for you ( a couple of lines )

I don't like it. So I want to increase the chance to revert it, while it's still possible.

BTW, why it's useful to unpack omni.jar?
I don't know much about that file.

Are you still talking to them?  It seems the conversation ended in September.  How can you change their mind?

A significant portion of of Fx behavior is implemented in javascript which is packed in omni.jar, among other things.  It's sometimes useful to be able to examine or even modify it and 7-zip edit functionality would come in handy.

I'm not talking them now.
I hoped (and I hope it still) that when they will see possible problems with new layout, they revert it back.

What current status of that new format?
What Firefox versions use new omni.jar?
How many users of that new Firefox?

By "possible problems" do you mean something other than interop issues with external tools?  Because they've clearly decided to ignore those.  Are there other types of problems, that they're not aware of?

What current status of that new format?

It looks like it's not going to change.  This blog entry claims a "2-3x reduction in disk io" due to this central directory placement optimization.

What Firefox versions use new omni.jar?

Starting with 4.0 betas (not sure which one) and onward

How many users of that new Firefox?

It's still in beta so probably not a huge number, but once released, that will change.

- This blog entry claims a "2-3x reduction in disk io" due to this central directory placement optimization.

I don't think that real gain is so big.
Actually I'd like to see some benchmarks that show total time in ms for old and new layouts.

- It's still in beta so probably not a huge number, but once released, that will change.

That is why I still think that they can revert it back, when big number of users will see problems with new layout.

Well, Al_9x, just do some benchmarking, post in this forum and in theirs and watch the facts get acknoledged (or not).
If it's really so helpfull and you helped everybody acknowledging then you just made the world a (very little bit) better place.

Hello everyone,

there must be some additional reason for this problem. As I stated above it *does* work for me with 7-Zip 9.20 (0.2) on XP SP3 32-bit too, with omni.jar from FF 4.0 beta 7 (4.050.494 Bytes) from 05. Nov. 2010 without any difficulties out of the box.

Best regards!

That is why I still think that they can revert it back, when big number of users will see problems with new layout.

Fx 4.0 is now at release candidate stage, the chances of the layout changing for 4.0 are 0

The fix is only 2 lines in 7-zip code

In light of the above and the fact that winrar 4.0 and xp zip viewer can handle omni.jar layout, can you please implement this?

There are chances even after ff 4.0 release.
Actually I don't like that idea with changed format.
I hope that ff developers will see it too.

Actually I don't like that idea with changed format.

Why not  simply think of it as a "broken" zip file that 7-zip is nevertheless capable of opening?  What is the downside?  I've started using 7-zip due to the variety of formats it could handle.  How can the ability to open more files be a bad thing?

There are chances even after ff 4.0 release.

I hope that ff developers will see it too.

What's going to make them see it?  Are you expecting an avalanche of angry users?  That's not going to happen.  This hurts a very small % of power users who might be interested in live editing files inside omni.jar.   Simply extracting is not a problem, since other popular tools can do that.

I think that this change.is bad thing .
Most of FF developers still don't understand how bad is it. I hope that will see it.

Original developer of that change claims that it's for speed optimization.
But I haven't seen any real benchmarks that proves it.

So now it looks like that they break standard and there is any real gain. Why to help them do wrong things?
It's better to allow them to revert back to righ way.

I think that this change.is bad thing

But I haven't seen any real benchmarks that proves it.

Good or bad, proven or unproven, what matters is that it's done, that's the significant fact confronting the user.  Your protest is highly unlikely to undo it because there will be no popular reaction against the change, for a couple of reasons: a. not that many people care.  b. other tools (winrar, zip folders) support the layout.  So the choice is to help your users open this (call it broken, invalid, non-standard) archive or not.  Choosing not to, only hurts your users, does not accomplish anything else.

Why to help them do wrong things?

You would not be helping them do anything, they've already done it, and evidently don't care if 7-zip can open this archive or not.  The ones you would be helping are your users.

Just answer some questions:
1) Does it break ZIP standard?
2) Is it good to break ZIP standard?
3) Do we need to protest against it and how?

If most of programs ignore that hack change, people even will not know about that bad thing.

So let's wait FF release.
It's interesting too see whether users can change such bad thing in FF.

Hello everyone,

will someone please enlighten the the dumb?!
As I wrote above -> I never (to the best of my knowledge) had this problem! 7-Zip opens / extracts / tests omni.jar without *any* complain! I did try that with 9.20.02 on XP, SP3 and did try it with 9.20.06 today with latest omni.jar (from today FF 4.0 RC1):
7-Zip:
- unpacking works fine
- testing the archive works fine

Archives: 1
Directories: 172
Files: 1531
Size: 11772151 (11 MB)
Compressed Size: 4215247 (4 MB)
No errors occured.

Windows (now Win 7 Starter):
right-click on omni.jar -> Properties -> "Size: 4,01 MB (4.215.247 Bytes)"
right-click on all selected files inside the folder "omni" (after unpacking with 7-Zip):

1531 files, 173 Directories
11,2 MB (11.772.151 Bytes)

Am I missing something?
Note: dialog-entries have been translated by me from german to english where needed.

Best regards!

Does it break ZIP standard?

I am not an expert on the standard, but I can tell you this, WinRar, WinZip, Windows Zip Folders, PKZip all handle this layout.  Of the major archive utilities, you appear to be the only holdout.  In practice, the standard is what the major implementers agree on, so this layout appears permissible.  My guess is that the above mentioned utilities account for 80% of zip (de)compression.  Though pkzip is probably not very popular, they are the creators and maintainers of the zip format, and they too consider this layout to be acceptable enough to open.

Do we need to protest against it and how?

No we don't need to protest, we need to add those two lines of code and be done with this.

will someone please enlighten the the dumb?!

Haha, vacon, nicely said! Btw: That quote would make a nice title for a book or a blog or something like this…

To al_9x: will you please await the FF release already?
And it would be very nice when you could push yourself a little and if you show a little bit of understanding for the arguments of 'the other side' of the discussion.
Also please reread everything vacon wrote in this thread.
Thanks. Seriously.

vacon:

Yes, latest firefox 4.0 RC 1 conains "good" omni.jar.
But at least one beta version of FF in past (in september 2010 as I remember) conatained hacked omni.jar.
I didn't check it after that.
So maybe FF developers reject that hack already.
Can somebody confirm it?

I was trying to get a look in to the 'open and transparent' dev process of ff to see whats the status of this.
I was not surprised to find that those guys seem to have changed it back without writing to the bug report (or did I miss something?)

https://bugzilla.mozilla.org/show_bug.cgi?id=605524

If I had to guess I would say there is a difference between the nightlies and the RC or whatever is closest to this.