Closed
Bug 541420
Opened 14 years ago
Closed 14 years ago
Files extracted from XPI files have their executableness stripped
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
blocking1.9.2 | --- | - |
status1.9.2 | --- | .9-fixed |
status1.9.1 | --- | unaffected |
People
(Reporter: mossop, Assigned: mossop)
References
Details
(Keywords: regression)
Attachments
(2 files)
4.81 KB,
patch
|
robert.strong.bugs
:
review+
christian
:
approval1.9.2.9+
|
Details | Diff | Splinter Review |
603 bytes,
application/x-xpinstall
|
Details |
The tweaks we made to the extraction process in bug 526598 made us more forceful about ensuring the file permissions were correct but this has the side effect of removing any executable bit from the file permissions. We need to make sure at least the read/write permissions are there preserving the executable permissions.
Updated•14 years ago
|
Keywords: regression
Assignee | ||
Comment 1•14 years ago
|
||
Took a while to get a unit test that did a decent check on all platforms but I think this is it. The test zip file includes a file called "binary" that was marked executable before compressing, it should extract as executable as well. The fix just ensures we apply at least the file access bits we need at a minimum and allows any executable bits to pass through as well.
Attachment #423116 -
Flags: review?(robert.bugzilla)
Comment 2•14 years ago
|
||
Comment on attachment 423116 [details] [diff] [review] patch rev 1 Might be good to expand the comment to state that our code doesn't understand NTFS file permissions. Hopefully one day we will get that implemented.
Attachment #423116 -
Flags: review?(robert.bugzilla) → review+
Assignee | ||
Comment 3•14 years ago
|
||
Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/bee5caea0941, will look for branch approval shortly.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 4•14 years ago
|
||
Backed this out while I figure out what is up with the test failures.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 5•14 years ago
|
||
Relanded with an additional line of logging to try to narrow down where the problem is. The logging shouldn't affect most users and I'll remove it after a short period of time. http://hg.mozilla.org/mozilla-central/rev/5ad17deecfe0
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
blocking1.9.2: ? → needed
Comment 6•14 years ago
|
||
Where are we at with this?
Assignee | ||
Comment 7•14 years ago
|
||
(In reply to comment #6) > Where are we at with this? We have an intermittent test failure I can neither reproduce or understand which leaves me unable to be sure of how safe this is to take on branch. It appears that the failure hasn't happened in over a month though.
Comment 8•14 years ago
|
||
Ready for a branch landing yet?
status1.9.1:
--- → unaffected
status1.9.2:
--- → wanted
Assignee | ||
Comment 9•14 years ago
|
||
Comment on attachment 423116 [details] [diff] [review] patch rev 1 Yeah lets take this on branch, the intermittent failures appear to have gone away, I can't see any way that they could have been a code problem.
Attachment #423116 -
Flags: approval1.9.2.5?
Comment 10•14 years ago
|
||
Comment on attachment 423116 [details] [diff] [review] patch rev 1 Approved for 1.9.2.5, a=dveditz for release-drivers
Attachment #423116 -
Flags: approval1.9.2.5? → approval1.9.2.5+
Assignee | ||
Comment 11•14 years ago
|
||
Landed on branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/49004ea8ba6f
Comment 12•14 years ago
|
||
the test extension attached doesnt seem to verify the fix against 1.9.2.5. reopening. It does however, work against trunk nightly. Tested against on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7pre) Gecko/20100701 Namoroka/3.6.7pre
Updated•14 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 13•14 years ago
|
||
oops. this should status = verified fixed on trunk, and then i reset flags of blocking1.9.2 =? and status1.9.2 = ?. Please correct if i missed something.
Status: REOPENED → RESOLVED
blocking1.9.2: needed → ?
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 14•14 years ago
|
||
and verified fix on Minefield trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre.
Status: RESOLVED → VERIFIED
Comment 15•14 years ago
|
||
Comment on attachment 423116 [details] [diff] [review] patch rev 1 a-LegNeato for 1.9.2.8.
Attachment #423116 -
Flags: approval1.9.2.5+ → approval1.9.2.8+
Assignee | ||
Comment 16•14 years ago
|
||
Landed on the branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/df760e6d4ddc Looks like the right one this time too!
You need to log in
before you can comment on or make changes to this bug.
Description
•