Uploaded image for project: 'Jalview'
  1. Jalview
  2. JAL-746

incorrect permissions for InstallAnywhere installer on OSX

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 2.6.1
    • Fix Version/s: None
    • Component/s: Dev and Dep
    • Labels:
      None
    • Environment:
      Mac OS X 10.6 (?)

      Description

      Reported by Ben Eisenbaum:
      On 07/01/2011 17:31, Ben Eisenbraun wrote:
      >
      > Hi Jim,
      >
      > In the install.zip file for the 2.6.1 OS X release, it looks like there are
      > permissions problems. Unzip install.zip and running the resulting
      > install.app dies with this error:
      >
      > Jan 7 12:24:19 sbgrid-dev-flex com.apple.launchd[352] ([0x0-0x28e28e].install[24472]): posix_spawnp("/nfs/build/source/jalview/2.6.1/install.app/Contents/MacOS/install", ...): Permission denied
      >
      > Which is due to this:
      >
      > $ ls -l install.app/Contents/MacOS/install
      > -rw-r--r-- 1 bene ipausers 59184 Nov 15 10:27 install.app/Contents/MacOS/install
      >
      > Setting +x to the install file lets the installer run without problems.
      >
      > Thanks.
      >
      > -ben
      >

        Attachments

          Activity

          Hide
          jprocter Jim Procter added a comment -
          Followup from Ben Eisenbraun:
          Hi Jim,

          > > I tried to reproduce this on our snow-leopard box
          I figured out how to reproduce it. If I download the install.zip file and
          double click it, ArchiveUtility will expand it and the 'install' binary is
          +x.

          If I open a shell and run 'unzip install.zip', the resulting installer is
          broken because the 'install' binary is not executable. The NFS share
          doesn't seem to be a factor.

          Weird, eh?

          In any case, it's a minor issue. Most people are not going to be using a
          workflow like mine, so they're unlikely to encounter this problem.

          Show
          jprocter Jim Procter added a comment - Followup from Ben Eisenbraun: Hi Jim, > > I tried to reproduce this on our snow-leopard box I figured out how to reproduce it. If I download the install.zip file and double click it, ArchiveUtility will expand it and the 'install' binary is +x. If I open a shell and run 'unzip install.zip', the resulting installer is broken because the 'install' binary is not executable. The NFS share doesn't seem to be a factor. Weird, eh? In any case, it's a minor issue. Most people are not going to be using a workflow like mine, so they're unlikely to encounter this problem.
          Hide
          jprocter Jim Procter added a comment -
          Conclusion ? If you unzip the installer.zip manually rather than rely on OSX's tools to do it automatically, then permissions may not be set correctly.
          Show
          jprocter Jim Procter added a comment - Conclusion ? If you unzip the installer.zip manually rather than rely on OSX's tools to do it automatically, then permissions may not be set correctly.
          Hide
          jprocter Jim Procter added a comment -
          this still happens with an Installer built with InstallAnywhere 2012. It might be that the default archiver (which is Keka on my 10.6.x machine) affects whether permissions are honoured after unpacking the ZIP.
          Show
          jprocter Jim Procter added a comment - this still happens with an Installer built with InstallAnywhere 2012. It might be that the default archiver (which is Keka on my 10.6.x machine) affects whether permissions are honoured after unpacking the ZIP.

            People

            • Assignee:
              jprocter Jim Procter
              Reporter:
              jprocter Jim Procter
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: