Issue 82: automate stdio session does not see external db changes

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.