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
