Re: built app not unzippable
Re: built app not unzippable
- Subject: Re: built app not unzippable
- From: Matt Neuburg <email@hidden>
- Date: Fri, 07 Apr 2006 19:43:54 -0700
- Thread-topic: built app not unzippable
On Thu, 06 Apr 2006 21:30:33 -0700, Matt Neuburg <email@hidden> said:
>I built my app in the usual way (xcodebuild clean install and so on) and
>proceeded to distribute it. But an odd thing happened. I zipped the app
>using Tiger's "Create Archive of..." command, and posted the zip file.
>Others, downloading this zip file, complained it wouldn't unzip. And indeed,
>I tried it on my own machine: I zipped the app, and couldn't unzip the
>result (so it has nothing to do with upload / download, as the problem
>happens all right there on my machine).
>
>The unzip process gives a very odd error: "Unable to unarchive
>"MemoryStick.zip" into [whatever]: Error 17 - File exists."
>
>If I use OpenUp or StuffIt Expander to open the zip file, everything is
>fine; it is just the default unzipper, BOMArchiveHelper, that is choking
>(but of course that is what everyone uses so everyone experiences the
>problem).
>
>Is there a bug in BOMArchiveHelper? Is this a problem caused by some recent
>security update? If so (and this is what I'm leading up to), might there be
>something wrong with the way I'm building the app that causes it to be
>non-unzippable when zipped?
Okay, here's the deal. Cameron Hayne did a bunch of experiments on my app
and decided that the problem is as follows. First of all, what's changed
here is the addition of the Growl framework. Frameworks, as you know,
contain symlinks. Now, here's the top level of Growl.framework (with the
dates and owner info cut, for brevity):
lrwxr-xr-x Growl -> Versions/Current/Growl
lrwxr-xr-x Headers -> Versions/Current/Headers
lrwxr-xr-x Resources -> Versions/Current/Resources
dr-xr-xr-x Versions
Now, you'll notice that the first three things are symlinks to stuff that's
inside the fourth thing, the Versions directory. So far, so normal. However,
when you do an install build of an application, then, assuming you don't
touch the INSTALL_MODE_FLAG, all directories are hit by chmod with a setting
of "a-w,a+rX". Therefore Versions (and the stuff inside it) has no write
permission.
Cameron worked out that this is the problem - but only for BOMArchiveHelper.
When BOMArchiveHelper zips this, it makes something that it, itself, cannot
unzip. This seems like a bug in BOMArchiveHelper, seeing as OpenUp, StuffIt
Expander, and (most important) the built-in "unzip" can all unzip it just
fine. (Cameron zipped my app and then ran "unzip -l MemoryStick.app.zip" and
it was just fine.)
The question here is: where's the bug? Well, I am guessing that there is
nothing wrong with my build procedures or my build settings (do correct me
if I'm wrong), and so the culprit here is BOMArchiveHelper itself. As I said
in my previous post, I'm guessing that something happened in a recent
security update. It is, I'm thinking, a bug for BOMArchiveHelper to make a
zip file that it can't unzip, especially when what it is zipping is
perfectly legitimate stuff as here.
So:
(1) Be warned. If you have a framework embedded in your app, this could
happen to you. Your users will come to your house and break your furniture
over your head if you distribute a zip file they can't unzip, or if they zip
your app and find it won't unzip.
(2) If I can get some agreement that this is a bug in BOMArchiveHelper, I
will file it.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden