René Micout wrote:

>> Le 15 janv. 2015 à 15:17, dunbarx at a écrit :
>> You know, recently I tried to make a "splash" standalone in 6.7,
>> the first I needed to in a while (the last was in 5.x) and it
>> would not work. I thought it was something I was doing wrong,
>> but was not on my front burner to figure out.
>> Anyone else? This is big if true, but how could it have gone
>> unnoticed?
> Hello Craig,
> See bug report 14295 !

This is apparently related to a relatively recent change by Apple to security handling in OS X.

From the Release Notes included in all 6.7.x builds from 6.7.0rc2 on:

    Non-executable file redirection on Mac (6.7.0-rc-2)

    Mac AppStore rules require that only executables (including
    bundles and apps) are present within the Contents/MacOS
    folder in the application bundle.

    However, historically (for cross-platform purposes), LiveCode
    applications traditional place resources relative to the
    engine executable, resulting in non-executable files to be
    present in the Contents/MacOS folder which violates AppStore
    signing policy.

    To remedy this situation without requiring users to change
    scripts, a simple redirection facility has been implemented
    in the engine:

    If an attempt is made to open a file for read which falls
    within Contents/MacOS and does not exist, the engine will
    attempt to open the same path but under Contents/Resources
    /_MacOS instead.

    If an attempt is made to list files in a folder which falls
    within Contents/MacOS, the engine will list files in that
    folder and concatenate them will files within the same folder
    under Contents/Resources/_MacOS. Additionally the standalone
    builder has had an extra processing step added on Mac:

    After the Mac bundle has been built, the S/B recurses through
    Contents/MacOS and creates an identical folder structure based
    at Contents/Resources/_MacOS. All non-executable files in any
    folders under Contents/MacOS are moved to the same folder under
    Contents/Resources/_MacOS whereas any Mach-O executable files
    are left where they are.

    The result of this is that after building a standalone, from
    a script's point of view nothing has changed; but the app bundle
    will conform to the rules required for signing for the Mac

While the absence of reports related to general file access in the bundle would seem to suggest this change was implemented well in the engine, René's report shows this workaround for Apple's new security policy needs to be added to the SQLite external as well.

Hanson's confirmation there suggests they're working on it now, and given how widely SQLite is used I'd be surprised if the fix isn't in the next build.

There is one remaining issue however: René's last comment in the report suggests an expectation that files within the bundle will also be writable, but write access to anything within the Applications folder is generally disallowed on most systems, including OS x.

Does OS X now allow user-data to be written within an app bundle?

It would seem simpler to store user data in one of the user-writable folders within the user's Home folder, perhaps Application Support or another relevant path obtainable with the specialFolderPath function.

 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to