Hello,
I saw the changelog about the new beta, and curios about if that fixed some of my previously reported ZIP issues wanted to give it a try... the result is that it now seems to create "invalid archives"... at least to Mozilla's eyes...
My main use of ZIP is to create XPI packages, so this just feels kinda weird 
It's possible to make the timesamp/attrs change on folders optional?
Please tell us how to reproduce what you're seeing. i.e. An example of what are you zipping up and what are the exact steps & parameters used to create the zip.
A copy of one of the "invalid" zips could also be useful so we can see if it is really invalid, or if Mozilla just doesn't support some newer aspect of the zip spec (which you might be able to turn off in Opus, or we could add another option for if you can't turn it off already).
It may also be worth seeing if tools like 7-Zip and WinRAR are happy with the file. If they are then it points towards Mozilla being where the problem is.
And what information do you get if you click "see full validation report"? It may not be saying the archive format is invalid; it could be something about the way the files inside the archive are structured that Mozilla has a problem with.
Hi Leo,
The button i use to create XPIs is in my other (pointed) post, my settings are as follow:
I'll next send you a PM with two packages. The 0.1-orig package is one add-on i've submitted to AMO some days ago, and whose validation passed with no such error. Now, i just have to decompress this version, re-package it with DO 10.5.0.1 and submit it again to AMO to get the "invalid archive" message (anyone familiar with AMO would say i cannot submit two packages with the same version number, but in such case the error message would be "this version already exists" - actually i was trying to upload a new version when i first noticed this)
Thanks.
Hi again,
I have no much idea about Python, but checking ther AMO Validaotr's source-code, i can guess it's either a wrong filename[1] or maybe a wrongly reported directory's filesize[2] (?)
[1] : github.com/mozilla/zamboni/blob ... ls.py#L301
[2] : github.com/mozilla/zamboni/blob ... ls.py#L355
There is another place where the sentence "Invalid archive" is used[3], but i don't think it's a file too big issue (unless wrongly saved by the ZIP writer)
[3] : github.com/mozilla/zamboni/blob ... ls.py#L306
Hope that helps!
Thanks!
I think I see what's going wrong, but we need to look into it a bit more.
You can probably stop the problem from happening (and get an archive like 10.5.0.0 would have given) for now by adding COPYATTR=no to your command.
I don't think you need any of the other lines in that command, nor the UPDATEALL argument, by the way. This is probably all you need:
Copy ARCHIVE=keepfolder CREATEFOLDER="{s|nopath|noterm}.xpi" HERE WHENEXISTS=merge,replace FORCE COPYATTR=noThank you Leo! That did the trick 
Great
Jon's found and fixed the underlying problem so you can include attributes if you want again in 10.5.0.2 when it comes out.
It'll involve bigger archives or was that part of the bug? If so i'll keep it as-is, for me like if you want to add an option to completely remove all attrs, after all they aren't needed for add-ons
If you include directory attributes it'll make the archive slightly bigger, no way around that, but it'll stay optional so it's up to you when/if they are stored.
What i've noticed is that creating an archive with just four files (the files of the XPI i sent you, without the chrome directory) also causes a bigger archive if COPYATTRS=no isn't used. And all attrs (protection bits/datestamp) are the same on both archives.