René Micout wrote:
>> Le 15 janv. 2015 à 15:17, dunbarx at aol.com 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
AppStore.
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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
