On 11 Nov 2013, at 2:01pm, L. Wood <lwoo...@live.com> wrote: > * A user could move the file during a transaction, i.e., between > _prepare_v2(); and _finalize(); > > It seems that SQLite needs support for this situation. Would you agree? > > If so, the question is how. Maybe through callback functions requesting an > updated directory when needed? Or by internally following the changed path of > the main database file instead of storing it in memory at the outset? > > Until then, I guess I just have to live with the risk of either an error or > data corruption when a user moves a document (a package).
First, a user has to be pretty into Macs to even know where to find data files for a sandboxed app, and how to delete/move them. It's really not easy. Second, every other kind of data file from every other database has the same problem. Even if you were keeping your database in a text file, someone could still move that text file while your app had it open, meaning that the next time your app was run it would say it had no data at all. As for your remedy, yes I agree that OS X's ability to notify your app when one of its files is moved is pretty neat. But Mac users are a tiny minority of the billions of installations of SQLite and such a feature isn't important enough to put in a 'lite' database. And also, what do you expect SQLite to do if it notes such a movement ? Return an error message ? It already does that. 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. If you get it working neatly, it could be released for the Mac/SQLite community at large. Personally, I agree with Stephen: if my users want to mess with my app's data files they deserve everything they get. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
