copy files step of build is removing my executable bits

I’m at a loss to see what is happening. I’ve got several helper command line apps that I use a copy files step in build automation to place into the resources folder of the app. This is on MacOS. It’s worked perfectly for years but today I went to move an app from my development machine to a test server and several of the helper apps refused to startup. Looking things over I found they had no executable bits set. But only some of them. The bits are set in the folder they are copied from, but not set in the folder they end up in.

I had just upgraded the IDE to 2016r4.1 so I thought that was it and tested with 2016r4 but it did it there too and I KNOW I’ve used that to build release versions of the app which are fine. So it must be something on my machine thats causing it. Here are 2 helper apps from the source folder, both have the executable bit set, but upon copying the one from the CM11.isf file is gone:

-rwxr-xr-x@ 1 james staff 65932 Sep 12 2011 cm11.isf -rwxr-xr-x@ 1 james staff 98632 Mar 29 2014 cm15.isf

and then after the copy step into the real application they look like this:

-rw-r--r--@ 1 james staff 65932 Sep 12 2011 cm11.isf -rwxr-xr-x@ 1 james staff 98632 Mar 29 2014 cm15.isf

This happens to lots of these. Why would it copy the files but not preserve the permissions on them? Now I see those “@“ at the end of those lines and I don’t think those used to be there. Did something on my system add ACL’s or xattrs to these files and thats whats blowing it up? I will look up how to remove those for the next step in my own testing. Any other thoughts about what could be causing the copy files step to choke on them when it’s worked literally for years would be much appreciated. Thank you!

you could run a shell script in a build script to copy with command line tools and use -a flag.

I could build my own copy step as a shell script yes, but this used to work :wink: Whats different now?

I went through and recursively removed all the ACL’s and xattr’s and now my original source folder for them looks more clean, like this:

-rwxr-xr-x 1 james staff 65932 Sep 12 2011 cm11.isf -rwxr-xr-x 1 james staff 98632 Mar 29 2014 cm15.isf

yet after building the app and having it do the copy step what I end up with in my app is this:

-rw-r--r--+ 1 james staff 65932 Sep 12 2011 cm11.isf -rw-r--r--+ 1 james staff 98632 Mar 29 2014 cm15.isf

this is even worse now as the execute bit is gone on both the files and it’s added a “+” which means that there is now a new ACL attached to the file! I didn’t do that, what did that? If I list out the ACL’s for the 2 files I get this:

-rw-r--r--+ 1 james staff 65932 Sep 12 2011 cm11.isf 0: user:_spotlight inherited allow read,execute,readattr,readextattr,readsecurity -rw-r--r--+ 1 james staff 98632 Mar 29 2014 cm15.isf 0: user:_spotlight inherited allow read,execute,readattr,readextattr,readsecurity

Which seems to indicate that it’s moved the execute flag into the ACL? Except the system doesn’t recognize that as it won’t run that way.

Have you upgraded your os since the last time it worked?

I had to change from cp to ditto after having fun with the permissions. As last step in the installation process the permissions are checked again.

I believe that I’ve updated from 10.12.1 to 10.12.2 in the meantime. Something has definitely changed, I can’t do a copy from the command line without adding ACL’s and removing execute flags. i’ve written an IDE script to do the copy with the -pXR options to /bin/cp but even that creates an ACL list when it shows up on the other side. It does at least preserve the execute flag which the built in copy files step in xojo no longer does. Then another step to doShellCommand and chmod -RN to make those new ACL’s go away too. This is a total hack as I’ve had to hard code the source directories into it having trouble finding the proper IDE scripting values for where the project is located, but it’s a start.

I will try that too, thank you!

If none of that works I suppose I could call to osascript to tell the finder to do the copy and see what happens :wink: But I’m not at all confident that will work if the command line tools are hosed!

Thanks for the hint! I checked it out and this seems to do it the right way:

http://osxdaily.com/2014/06/11/use-ditto-copy-files-directories-mac-command-line/

I use a bash script into one of my projects from 2013 in the MAS that I updated this week, and it still works like clockwork, so I checked what I had used to place it in Resources.

It happens so I had simply dragged it into the project. In 2016R4.1, it still works just fine.