On 4/25/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On Wednesday, April 25, 2007, at 10:02AM, "Jack Jansen" <[EMAIL PROTECTED]> > 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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
