#221 Unpack glitch: Installers for up

Devin Poolman
David Braden

When the .zip installers for and are downloaded to
my machine (G3, OS 10.1.5), OpenUp 3.2 doesn't unpack them
correctly, whereas Stuffit Expander 6.5 does (go figure).
HTH, and thank you soooo much for your efforts.
Dave Braden


    • assigned_to: nobody --> devinpoolman
  • Logged In: YES

    Yes, we are not sure whether the problem is with the .zip files made by InstallAnywhere or with OpenUp. We have reported this issue to Zero G Software, but otherwise all we can do is advise people to use StuffIt Expander.

  • Devin Poolman
    Devin Poolman

    Logged In: YES

    This is because the .zip file doesn't maintain any
    permissions information, so extracting it does not make the
    .app bundle executable. This works with Stuffit Expander
    because it special cases .app bundles and makes them
    executable. I spoke with the developer of OpenUp and he
    provided me details on how to use metadata in the ZIP
    archive to preserve permissions, but InstallAnywhere does
    not support this (I don't see InstallAnywhere supporting
    this anytime soon).

    To handle this, we could distribute the installer as a disk
    image instead of a ZIP. As I am not very actively involved,
    I'm not sure how this would effect the build process. Any

  • Logged In: YES

    Interesting. Earlier versions of InstallAnywhere (used with the XFree86 4.2.0 install in XInstall_10.1.sit) produced .sit files instead of .zip. This avoided .zip's permission peculiarities. Disk images would be fine as well. I don't have a particular opinion on the best format. Typically disk images (.dmg) come as MacBinary (.bin) encoded.

    It would be very nice if InstallAnywhere built Mac OS X installers in a compressed format that was less fragile. I suppose we can do this by hand by recompressing the installer with another tool, and I'll try to do this in future releases. It would be something that would good to have InstallAnywhere take care of for us down the road so it "just works".

  • Devin Poolman
    Devin Poolman

    Logged In: YES

    Here is the academic discussion:
    Earlier versions of InstallAnywhere used a ZIP file renamed
    to .sit to workaround an early bug with Internet Explorer on
    Mac OS X. Regardless, the archives have always been ZIPs.
    Once they were renamed .zip, that brought up this issue with
    people using OpenUp and the file permissions not being set
    correctly. I agree, it would be very nice to handle this
    automatically, but doing so in ALL cases would really
    require us to use something other than ZIP (any fixes to
    work with OpenUp would just be hacks anyways since there is
    no true standard for preserving file permissions in ZIPs).
    Not using ZIP is tough for a Java, multiplatform application.

    Here is the best solution:
    Change the project fo build "CD-ROM installers"
    (non-archived, .app package) and not "Web Installers"
    (archived, single file). Then tackle the problem of making
    a .app package downloadable as a single file by either tar
    ball or disk image.

    If I can help with any of this, let me know.

  • Logged In: NO

    dunno if this is related to the unstuffing question, but the
    XFree86_4.2.0.1-10.2 installer has been sitting @
    "installing ... Info.plist" for over an hour now, no
    progress shown on the prog.bar:-( and of course, the
    XFree86_4.2.1.1 installer won't w/o

    and 4.2.0 runs just fine on 10.2.2

  • Logged In: YES

    Regarding the freeze at "Installing... Info.plist": This is discussed elsewhere in the help forums, but the problem is that the installers made by InstallAnywhere are not compatible with Apple's developer preview releases of Java. Check http://sourceforge.net/forum/forum.php?thread_id=754266&forum_id=57137 for more info and a work around. I assume Zero G and Apple are aware of this issue and it will be fixed for the next official release of Java.

  • Devin Poolman
    Devin Poolman

    Logged In: YES

    We (Zero G) know we have a problem with Java 1.4.1 on Mac OS
    X because they dropped JDirect and a number of the MRJ
    classes (very nice of Apple to do this so suddenly). We are
    working with Apple on how to handle this in the long term,
    and our next release will have a flag to force the app to
    run against 1.3.1. In the mean time, we should be able to
    set this flag manually in the info.plist "JVMVersion=1.3*".

    • status: open --> open-fixed
  • Logged In: YES

    The latest installer for XFree86 4.3.0 (also built with
    InstallAnywhere) has this issue and the Java 1.4.1 issue fixed.

    • status: open-fixed --> closed-fixed