Execute flag missing from bin/prog with sbt task universal:packageBin when zipped and unzipped in OS X

[akauppi]

Hi,

thanks a Million for sbt-native-packager. Have found one minor bug I'd like to report - unfortunately don't have time to do more on this. Occurs on both 0.7.1 and 0.7.5-RC1.

If I do sbt stage task, the bin/myapp file has execution attribute, as expected.
If I do universal:packageBin (i.e. allowing sbt to zip the package for me), it doesn't.

I'm using OS X 10.9.4 and Java 1.8.0_11-b12 if that matters (though I'm not 100% sure which JDK gets kicked in for the zipping).

[akauppi]

Seems Ubuntu 14.04 LTS unzips the package nice, with execution flag on.

So to narrow down the bug: unzipping on OS X 10.9.4 leaves the bin/myapp file without the execution flag.

[muuki88]

Thanks for tracking this! @kardapoltsev can you reproduce on one of your linux systems (centos, gentoo,..)? If not, this is clearly a problem on Mac :(

[kardapoltsev]

I've tried this on Gentoo and Centos:

ll dtest-0.1.0/bin/
total 24K
-rwxr-xr-x 1 alexey alexey  13K Aug 31 17:51 dtest
-rw-r--r-- 1 alexey alexey 6.8K Aug 31 17:51 dtest.bat

Also, I've copied this zip file to MacOS, unzip and found that executable flag is on.

[muuki88]

@akauppi have you found a workaround? I couldn't get my hands on a mac to reproduce this.
My first guess would be that there is a problem with the ZipHelper.

Can you try to customize your build using useNativeZip. It should be something like this in your build.sbt

packagerSettings // I think using an archetype here is fine, too

useNativeZip

[akauppi]

Thanks, @muuki88 . I'll have a look tomorrow, but since we are not targeting OS X primarily, this is a low priority issue for us.

[akauppi]

Yes, adding the useNativeZip does cure the situation:

1. Running with it added to build.sbt (after packageArchetype.java_application):

$ rm -rf target/universal
...
$ sbt universal:packageBin
...
... unzipping the target/universal/*.zip (with OS X Finder):
...
$ ls -al target/universal/dash-0.3/bin/
total 40
drwxr-xr-x 4 askokauppi staff 136 29 Syy 23:50 .
drwxr-xr-x 5 askokauppi staff 170 29 Syy 23:50 ..
-rwxr--r-- 1 askokauppi staff 11355 29 Syy 23:50 dash
-rw-r--r-- 1 askokauppi staff 5772 29 Syy 23:50 dash.bat

There is an 'x' next for owner of dash file, i.e. it is executable.

1. Without the addition of useNativeZip (otherwise as above):

...
$ ls -al target/universal/dash-0.3/bin/
total 40
drwxr-xr-x 4 askokauppi staff 136 29 Syy 23:54 .
drwxr-xr-x 5 askokauppi staff 170 29 Syy 23:54 ..
-rw------- 1 askokauppi staff 11355 29 Syy 23:54 dash
-rw------- 1 askokauppi staff 5772 29 Syy 23:54 dash.bat

As you can see, it's not only the missing of the execution right, but missing of reading right from anyone but the owner.

[akauppi]

Also there in 0.8.0-M1

[muuki88]

Thanks for reporting back. I have to apologize to @jsuereth not reading his docs, which state:

Note: This is known to have some odd issues on MacOSX whereby executable permissions
are not actually discovered, even though the Info-Zip headers exist and work on
many variants of linux. Yay Apple.

So at the moment I recommend to use useNativeZip. When we swap to java7 or 8, we reimplement this logic with NIO.

[akauppi]

Sounds good to me. I'm also in the clear by the interim solution. Up to you if you wish to close this issue or keep it as a reminder.

[muuki88]

We'll keep this as a reminder :-)

[muuki88]

Bad news. NIO doesn't fix this either :(