Reported by Stephen Leake, Sep 11, 2010
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?31017) If an automate stdio session has opened a db, and some external process then changes that db, the stdio session does not see the changes. automate stdio should check to see if the cache needs to be refreshed. monotone version: ----------------- 0.48
Comment 1 by Stephen Leake, Sep 23, 2010
Actually, to trigger the problem, the external process has to delete and recreate the db. For example, by running a lua test. Normal operations on a database are seen by the stdio process.
Comment 2 by Thomas Keller, Sep 23, 2010
Can we instruct the operating system to lock the opened database file somehow so it cannot be deleted / unlinked while its open?
Comment 3 by Stephen Leake, Sep 26, 2010
Further experiments; on Windows MinGW and Cygwin, the automate session does hold the database file locked; an attempt to delete it from another process fails. On Debian Linux, the file is not locked; deleting it from another process succeeds. This would seem to be an SQLite issue.
Comment 4 by Unknown User, Sep 26, 2010
There is no such thing as locking against deletion on Unix. How exactly did you get into this situation, Stephen? The lua tests are supposed to only mess with databases that they create.