Storing and saving a setting in a stand alone

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com