If the database files are being handled as a document, what I would suggest then is to use SQLites Backup API, and work off of the backup API.
http://www.sqlite.org/backup.html This means that the user is going to be free to do whatever they want with the file in their documents directory. When you create your backup file, put it somewhere where the user isn't going to be playing, or, even back up to :memory: (Speed gain will be nice, depending on how large your document is). On Tue, Nov 12, 2013 at 7:24 AM, L. Wood <lwoo...@live.com> wrote: > Thanks for the replies. I'd like to address some of your comments so far. > > -- > Stephan Beal: > > > If the app is sandboxed, how does the user possibly > > get a chance to move the files? > > A sandboxed Mac OS X program can gain access to regular user-selected > documents (files or directories). And of course, users can move around such > documents. That doesn't change when the program is sandboxed. > > > Until you asked about this last week i had never heard > > of a use case where any app needs to account for its data > > files being moved while it is running. > > I may not have mentioned this clearly, but I wasn't discussing moving the > program's data files. The program's data files are located within some > ~/Library subdirectory and of course I'm not trying to handle the user > messing with those. > > What I'm trying to handle is the user moving *regular documents* around. > As I mentioned, such a document is in my case a package (directory) that > contains the SQLite database file. Being a regular document, the user can > move it around like any other document. > > > If it's on the same device it's just a > > rename and the inode stays the same. If it's across devices then it's > > basically a copy+delete. > > Yeah, I'm aware of this case and there is nothing one can do here. A > "move" to a different device always has to be equivalent to a delete, > unfortunately. > > -- > Simon Slavin: > > > ...where to find data files for a sandboxed app... > > Please see above replies to Stephan. I'm not discussing data files. Sorry > for the confusion. > > > Besides which, you can write it yourself externally to SQLite: > > use FSEvent on the folder your database is in checking for > > kFSEventStreamEventFlagItemRemoved, and act accordingly. > > No need to put that facility inside SQLite. > > The problem is that the user could move a document *during a transaction*, > i.e. between _prepare_v2() and _finalize(). SQLite saves the old path into > memory when a -journal file is created. Sure, I can watch the file moves > myself as you suggest, but there is nothing I can do to influence SQLite in > this matter. Hence my feature request. > > -- > Tim Streater: > > > It's unclear if the OP wants to do this or expects to be > > able to move the whole lot while the app is running, which > > is not something I'd expect to be able to do. > > Sorry for the confusion. I'm talking about moving individual documents. > See above replies to Stephan and Simon. > > -- > Stephen Chrzanowski: > > > they shouldn't be playing with the file structure to begin with. > > Sorry for the confusion. I'm talking about moving individual documents. > See above replies to Stephan and Simon. > > > Basically, with SQLite anyways, I think that if you have a file that is > > moved during a transaction, your results are going to fall under the > > "UNDEFINED" category. > > I'm afraid you're right. That's the way it is now and that's why I posted > the feature request :) > _______________________________________________ > 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
