[Pythonmac-SIG] StuffIt 10 can corrupt applications packaged with py2app

Bob Ippolito bob at redivi.com
Wed Apr 25 11:53:33 CEST 2007


On 4/25/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On Wednesday, April 25, 2007, at 10:02AM, "Jack Jansen" <Jack.Jansen at cwi.nl> wrote:
> >
> >On 25-apr-2007, at 7:50, Ronald Oussoren wrote:
> >
> >>
> >> On 24 Apr, 2007, at 5:45, Brian Christensen wrote:
> >>
> >>>
> >>> Following up on this lead we found that there is a problem with
> >>> StuffIt 10. My application was distributed as a zip file so the user
> >>> used StuffIt to unzip the file. It turns out that StuffIt was
> >>> unzipping and deleting the site-packages.zip inside of the
> >>> application!
> >>
> >> That's very lame behaviour on StufIt's part.
> >
> >It's a preference. In Stuffit Expander it's called "Continue to
> >expand if possible", in the full stuffit it's probably something
> >similar.
> >It's on by default, it's what makes stuffit do the full decoding and
> >unpacking of, say, a .tar.gz.
>
> I'll see if I can whip up a patch that add the workaround I described to the code generated by py2app, there's bound to be more users that use Stuffit.

I've had other strange problems with StuffIt's zip support that aren't
directly relevant to py2app. For example I have a folder full of a
bunch of text files (ActionScript source code) and if I zip it with
BOMArchiveHelper, Python, *or* the zip command line tool then StuffIt
refuses to unpack the archive with a strange error code. I actually
have to use StuffIt or Windows to pack the archives in order to get
something that is unpackable by StuffIt.

The strangest thing is that there is absolutely nothing strange about
the archive. A few folders with three-four character names, some files
with all ASCII names less than 8.3 characters long, etc.

StuffIt should die. It's sad that they broke the only de facto
standard for cross-platform archives :(

-bob


More information about the Pythonmac-SIG mailing list