> Simon Slavin wrote:
> If you can't trust your users not to
> move data files out of place
I was not talking about data files but regular documents (package folders).
Moving regular documents has nothing to do with trust. It's a fact of everyday
reality.
> Stephen Chrzanowski wrote:
> Even with MySQL, if you start messing around with directory
> structures, file permissions, or whatever, you're GOING to
> kill the software.
Moving regular documents is not "messing around" with anything.
> William Garrison wrote:
> It's your job to code for this possibility. Use the
> rest of the system to help you do that.
> Simon Slavin wrote:
> My conclusion is that those programmers who want this
> can do it inside their app, outside the code which handles
> the database itself.
> Stephen Chrzanowski wrote:
> File handling is NOT SQLites responsibility, but your
> applications responsibility in knowing how the OS
> handles itself.
I can think of two ways to "achieve" this (neither actually works):
* Before every single SQLite C function call that accesses the database, check
whether the document has moved. This is horrible for two reasons: (1) It will
slow down the database operations. (2) The document could still be moved
*between* our "move check" and the database operation.
* Using fsevents etc. to monitor the document move, as someone suggested. This
will not work because lengthy database operations occur on a separate thread,
so the database can get corrupted *before* we actually handle the document
move. And even if fsevents and database operations are handled in the same
thread, there is no guarantee that the system sends my program the event before
the database gets corrupted.
Summary: AFAIK, there is nothing my program can do to handle this.
So IMO, this is a problem that SQLite should cope with. At most, it should give
us errors to deal with - not corrupt the database.
If you disagree, why?
If you agree:
Let's go back to D. Richard Hipp's original (1)-(5) steps of corruption.
Could there be a way for a future version of SQLite to avoid that corruption? I
asked whether opening the journal file only once was a potential solution to
this. I'm not sure it is. If not, why not, and do you have any other ideas?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
