You obviously understand the problem. The clean and tidy way to make a copy would be to incorporate it into Sqlite as an API call and use the locking primitives and the open file handle. It would be very fast and safe.

Cyrus Durgin wrote:
Right, my question was around how to copy the database file; simply opening
the file again from the OS isn't guaranteed to open the same file that's
locked (if the file is unlinked while sqlite has it open, and then recreated
before the call to fopen() or open() or whatever, for instance).  I'm not
too worried about this race condition under normal circumstances but for my
purposes consistency is important.

On 10/10/07, Ronny Dierckx <[EMAIL PROTECTED]> wrote:

I think a possible solution is to lock the database with a "BEGIN
statement and then copy the database file.

----- Original Message -----
From: "Cyrus Durgin" <[EMAIL PROTECTED]>
To: <>
Sent: Wednesday, October 10, 2007 6:41 PM
Subject: Re: [sqlite] how to get file handle from sqlite3 object?

Agreed - it seems like this would be useful enough functionality that


not sure everyone who needs it should be reinventing the wheel...

So is it fair to say that the sqlite3_file API methods are not useful


this purpose?  The docs are a bit sparse regarding their intended

On 10/10/07, John Stanton <[EMAIL PROTECTED]> wrote:

There is a good case to have an Sqlite API call to take a snapshot of a
database.  It would integrate with the locking logic and secure an
exclusive lock before taking the snapshot.  That is a safer and handier
approach than extracting a file descriptor and perhaps creating mayhem.

Cyrus Durgin wrote:

Maybe it would help to state my use case: without this functionality,


is the proper way to copy a database using the C API without


race condition?

On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote:

To unsubscribe, send email to [EMAIL PROTECTED]


To unsubscribe, send email to [EMAIL PROTECTED]

Reply via email to