Don't try to redirect the SQLite temporary files. In the long run, you'll be in for more maintenance. Instead work within the sandbox limitations.
Are you using SQLite as a file format or looking to edit arbitrary SQLite files? If you're making a custom file format, put the SQLite database inside a package (search for "nsdocument package" if you're unfamiliar with this). This makes sandboxing almost irrelevant since your app opens the root directory of the package and then your app has pretty much free access to anything inside that directory. This is bar far the easiest approach if you can use it. If you need access to arbitrary SQLite files, then you'll need to read up on NSFilePresenter and Related Items. I think this is mentioned in this one or two of this years WWDC videos. Try http://asciiwwdc.com for searchable transcriptions of the WWDC videos. It's more annoying and still has some bugs, but works. - Ben On 7 Nov 2013, at 17:42, L. Wood <lwoo...@live.com> wrote: > What directories can SQLite possibly write files to? > > Modern Mac OS X programs run in "sandbox mode". This is a requirement to > publish apps on Apple's Mac App Store. "Sandboxing" means that it is > impossible for an app to write files into locations outside a given > authorized "sandbox". > > For instance, a proper way to get a safe temporary directory is Apple's own C > API, NSTemporaryDirectory(). > > How would you adapt SQLite to this environment? > > > Here are my own thoughts so far (based on the webpage > http://sqlite.org/tempfiles.html): > > * I'm aware of the files that SQLite can write to the *same* directory as > that of the actual database file, and I have ways to deal with that (by > putting the database file into a so-called package, so all the files will be > together as a unit). > > * If I set the global variable sqlite3_temp_directory > (http://sqlite.org/c3ref/temp_directory.html) to the value returned by > Apple's NSTemporaryDirectory(), I'm hoping to be fine. Will I? > > Unfortunately, the webpage also says: > > "The manner in which SQLite uses temporary files is not considered part of > the contract that SQLite makes with applications. The information in this > document is a correct description of how SQLite operates at the time that > this document was written or last updated. But there is no guarantee that > future versions of SQLite will use temporary files in the same way. New kinds > of temporary files might be employed and some of the current temporary file > uses might be discontinued in future releases of SQLite." > > This renders any efforts in this regard ill-defined. Are there any solid ways > out? I'm using SQLite 3.8.1, and are the rules on what webpage even true for > this version? That is nowhere mentioned. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
