919428 - Can no longer successfully replace files in omni.ja, after Seamonkey 2.17.1

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[andré]

This refers to Seamonkey versions 2.19 (32bit) and 2.20 (64bit) downloaded form the seamonkey-platform.org/releases page.
(Don't know what to enter for the gecko version) 

Comparing with SM 2.17.1, still functioning on the same machine.

Note that the omni.ja file is now detected as an unknown file type in the graphical interface, instead of as a zip archive.  This means the file header must have changed, as the file name (and suffix) are identical.

Steps taken, with results :
1) Using the info-zip version of unzip, the file to be modified is extracted from omni.ja.  This proceeds normally.

2) The file is modified, initially slightly larger.

3) Using the info-zip version of zip, the file replaces the original version in omni.ja.  Omni.zip is larger in size, which indicates that the modified file was inserted at the end of omni.zip, instead of the previous location.

4) Seamonkey is started, and as expected, the part modified (email) is inaccessible.

5) The modified file is progressively reduced in size and reimported into (a fresh copy of) omni.ja until the compressed size as reported by the info-zip version of zipinfo is less than that of the original file.

6) The omni.ja archive is still larger than originally, and as expected, starting Seamonkey shows that the part modified is inaccessible.

What was expected :
a) In step 3, omni.ja stays the same size.  If not, step 5 would succeed in producing an omni.ja the same size.
b) The resulting omni.ja would be able to access the modified part successfully.

Note that identical modifications have been made since Seamonkey 2.0 or before.  Only since omni.ja* has there been any problems, essentially related to the size of the modified file.
Now something other than the size is blocking the update.


If anyone knows of a workaround, it would be appreciated.
I tried putting the modified file into the corresponding position in the chrome tree, to no avail.
It would be preferred to implement this patch globally, if at all possible.

Comment 1

[andré]

This problem still exists for seamonkey 2.21 (64bit)

Someone made a comment somewhere that the packager was rewritten for gecko, which affected seamonkey 2.19 and up.

Could I get hold of the packager, so I can use it to repack seamonkey.  That would work around this problem.  (As long as I can run it on Linux.)
Can anyone tell me where to find it ?

Comment 2

[andré]

I discovered that omni.ja need not be in the special format, which was not originally the case.
Just deflate compressing to a standard zip file (called omni.ja) works fine.
It also loads essentially as fast as it would in the special format.

So this bug is redundant.
Closing as RESOLVED/WONTFIX, since it isn't necessary.