On 12 Nov 2013, at 12:24pm, L. Wood <lwoo...@live.com> wrote: >> 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.
Doesn't matter because OS X is, at heart, Unix. Unix is a bit weird in that it allows you to move and delete a file which is open. Moving an open file does nothing to existing file handles: they continue to point to the data no matter what folder the file's in. Deleting the file removes the entry from the folder the file was in, but because the file is open the file remains on disk. When you release a file handle the FS checks to see whether the file appears in any folders or file handles and if not, /then/ it actually deletes the file. The consequence is this: while the journal file is useful (in other words, while SQLite has it open) the user can do what they like with the journal file but your app doesn't care. Its handle still works and the file won't actually be deleted. Eventually the transaction ends and SQLite closes the journal file because it no longer cares what's in it. At that point the file system can really delete the file. If SQLite's journal mode is DELETE, then SQLite also tries to delete the file (but can't, because the file was deleted by the FS). SQLite receives a 'cannot delete that file because there's no such file' which is ignores, and everything continues happily. So the only consequence of having a user move a journal file while SQLite is using it is that the journal file remains where the user moved it and never gets deleted. So it uses up a little disk space. No corruption results. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
