RE: [sqlite] how to get file handle from sqlite3 object?
the question of how to do a backup comes up a lot so this would be very nice. If it was added with a compile-time OMIT flag then there shouldn't be a big concern on bloating the library. Sam --- We're Hiring! Seeking a passionate developer to join our team building products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -Original Message- From: Virgilio Fornazin [mailto:[EMAIL PROTECTED] Sent: Thursday, October 11, 2007 2:21 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] how to get file handle from sqlite3 object? I'm thinking about this.. to get a 'exact' copy of a sqlite database we should implement a new public API: sqlite3 * sqlite3_clonedb(sqlite3 * db, const char * szOutput); sqlite3 * sqlite3_clonedb16(sqlite3 * db, const void * szOutput); // utf-16 version this api can do the real file copy without exposing any characteristics of the sqlite3 database (this db could be copied from / to :memory: databases on this way) and also deal with internal VFS driver intrinsics, such as sector size, and etc. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
I'm thinking about this.. to get a 'exact' copy of a sqlite database we should implement a new public API: sqlite3 * sqlite3_clonedb(sqlite3 * db, const char * szOutput); sqlite3 * sqlite3_clonedb16(sqlite3 * db, const void * szOutput); // utf-16 version this api can do the real file copy without exposing any characteristics of the sqlite3 database (this db could be copied from / to :memory: databases on this way) and also deal with internal VFS driver intrinsics, such as sector size, and etc. On 10/11/07, Joe Wilson <[EMAIL PROTECTED]> wrote: > > > > sqlite3OsFileHandle no longer exists. > > > Can you tell me the first sqlite3 version to include this change? > > I'm guessing that it's 3.5.0 when most of the code was revised. > > > > > > Yahoo! oneSearch: Finally, mobile search > that gives answers, not web links. > http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > > - > >
Re: [sqlite] how to get file handle from sqlite3 object?
> > sqlite3OsFileHandle no longer exists. > Can you tell me the first sqlite3 version to include this change? I'm guessing that it's 3.5.0 when most of the code was revised. Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
On Wed, 10 Oct 2007, Joe Wilson wrote:
> --- Andy Spencer <[EMAIL PROTECTED]> wrote:
> > I'm not sure what you mean by database "main", and I did not
> > write the functions.
>
> The default database name (really more of an alias) is "main".
> So "SELECT * from foo" and "SELECT * from main.foo" are the same.
> Attached databases are known by the name you've attached them as.
>
Then, yes, it would be the "main" database, since we do not attach
any other databases.
> > The functions use the pager to access the file descriptors:
> ...
> > int sqlite3pager_get_database_file_fd(Pager *pPager)
> > {
> > return sqlite3OsFileHandle(pPager->fd);
>
> Okay, I see. sqlite3OsFileHandle no longer exists.
> But then again, for your purposes it's moot, since FD_CLOEXEC
> is done for you.
Thanks for the information.
Can you tell me the first sqlite3 version to include this change?
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] how to get file handle from sqlite3 object?
--- Andy Spencer <[EMAIL PROTECTED]> wrote:
> I'm not sure what you mean by database "main", and I did not
> write the functions.
The default database name (really more of an alias) is "main".
So "SELECT * from foo" and "SELECT * from main.foo" are the same.
Attached databases are known by the name you've attached them as.
> The functions use the pager to access the file descriptors:
...
> int sqlite3pager_get_database_file_fd(Pager *pPager)
> {
> return sqlite3OsFileHandle(pPager->fd);
Okay, I see. sqlite3OsFileHandle no longer exists.
But then again, for your purposes it's moot, since FD_CLOEXEC
is done for you.
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] how to get file handle from sqlite3 object?
On Wed, 10 Oct 2007, Joe Wilson wrote:
> > At Schrodinger, we added two functions to our version of sqlite3:
> >
> > /* The sqlite3 APIs to get file descriptors fo the open files */
> > int sqlite3_get_database_file_fd( sqlite3* sqlite3_db_ptr );
> > int sqlite3_get_journal_file_fd( sqlite3* sqlite3_db_ptr );
>
> Do your functions always just return the fd of the first database "main"?
>
Hi Joe.
I'm not sure what you mean by database "main", and I did not
write the functions.
The functions use the pager to access the file descriptors:
In pager.c:
int sqlite3pager_get_database_file_fd(Pager *pPager)
{
return sqlite3OsFileHandle(pPager->fd);
}
int sqlite3pager_get_journal_file_fd(Pager *pPager)
{
if ( !pPager->journalOpen )
return -1;
return sqlite3OsFileHandle(pPager->jfd);
}
In fds.c (file added by Schrodinger):
int sqlite3_get_database_file_fd( sqlite3* sqlite3_db_p )
{
Pager *pPager;
if ( !sqlite3_db_p || !sqlite3_db_p->aDb || !sqlite3_db_p->aDb[0].pBt)
return -1;
pPager = sqlite3BtreePager(sqlite3_db_p->aDb[0].pBt);
if ( !pPager )
return -1;
return sqlite3pager_get_database_file_fd(pPager);
}
int sqlite3_get_journal_file_fd( sqlite3* sqlite3_db_p )
{
Pager *pPager;
if ( !sqlite3_db_p || !sqlite3_db_p->aDb || !sqlite3_db_p->aDb[0].pBt)
return -1;
pPager = sqlite3BtreePager(sqlite3_db_p->aDb[0].pBt);
if ( !pPager )
return -1;
return sqlite3pager_get_journal_file_fd(pPager);
}
> SQLite3 now has this code in os_unix.c:
>
> #ifdef FD_CLOEXEC
> fcntl(h, F_SETFD, fcntl(h, F_GETFD, 0) | FD_CLOEXEC);
> #endif
>
That's good to know. Our version (3.3.4, and later 3.4.0) did not
have this.
> Is that your only use for requiring the file descriptor?
Yes.
We set FD_CLOEXEC for the database fd when the database is opened,
and for the journal fd in the pthread_atfork handler.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] how to get file handle from sqlite3 object?
Andy, Thank you for your note. It is very useful. Andy Spencer wrote: On Tue, 9 Oct 2007, Joe Wilson wrote: --- Cyrus Durgin <[EMAIL PROTECTED]> wrote: i'm wondering if there's a "standard" way to get an open file handle from an sqlite3 pointer using the C API. anyone know? No such function exists, but it would be a useful addition to the API. Copying the database during an exclusive lock without spawning a process for instance... I agree. At Schrodinger, we added two functions to our version of sqlite3: /* The sqlite3 APIs to get file descriptors fo the open files */ int sqlite3_get_database_file_fd( sqlite3* sqlite3_db_ptr ); int sqlite3_get_journal_file_fd( sqlite3* sqlite3_db_ptr ); This was done to prevent the open files from being inherited by forked child processes, using fcntl(fd, F_SETFD, FD_CLOEXEC), since otherwise those child processes could keep the files open, thereby preventing deletion of the database files (and the directory that contains them) in the parent process. It would be better for us to have similar functions included as part of the standard sqlite interface. --- The database files are kept inside project directories, created by the same client application, to store data about project entries and their properties. In this application, there is expected to be only a single client process accessing the database, and the project is locked by the client to ensure this. Before adding these functions (in order to set the FD_CLOEXEC flag), we had problems with the deletion of scratch (temporary) projects or user deletion of projects, because child processes launched in the background (such as calculation job processes or browsers for online help) would by default inherit all open files. The database files are open essentially the entire time that the project is open, because we maintain an open transaction at all times (except for commit or rollback of changes to the project data) to improve performance and to handle single-level undo of data modifications (in the project, and in the application state). --- Andy Spencer <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
--- Andy Spencer <[EMAIL PROTECTED]> wrote: > On Tue, 9 Oct 2007, Joe Wilson wrote: > > > --- Cyrus Durgin <[EMAIL PROTECTED]> wrote: > > > i'm wondering if there's a "standard" way to get an open file handle from > > > an > > > sqlite3 pointer using the C API. anyone know? > > > > No such function exists, but it would be a useful addition to the API. > > Copying the database during an exclusive lock without spawning a process > > for instance... > > I agree. > > At Schrodinger, we added two functions to our version of sqlite3: > > /* The sqlite3 APIs to get file descriptors fo the open files */ > int sqlite3_get_database_file_fd( sqlite3* sqlite3_db_ptr ); > int sqlite3_get_journal_file_fd( sqlite3* sqlite3_db_ptr ); Do your functions always just return the fd of the first database "main"? > This was done to prevent the open files from being inherited > by forked child processes, using fcntl(fd, F_SETFD, FD_CLOEXEC), > since otherwise those child processes could keep the files open, > thereby preventing deletion of the database files (and the directory > that contains them) in the parent process. SQLite3 now has this code in os_unix.c: #ifdef FD_CLOEXEC fcntl(h, F_SETFD, fcntl(h, F_GETFD, 0) | FD_CLOEXEC); #endif Is that your only use for requiring the file descriptor? Another way is to pre-fork() one or more worker processes before any sockets, files or database connections are made. These pre-forked processes could take instructions from their parent and return information via a pipe(). Of course each worker process would have to re-open() all its own resources. Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
On Tue, 9 Oct 2007, Joe Wilson wrote: > --- Cyrus Durgin <[EMAIL PROTECTED]> wrote: > > i'm wondering if there's a "standard" way to get an open file handle from an > > sqlite3 pointer using the C API. anyone know? > > No such function exists, but it would be a useful addition to the API. > Copying the database during an exclusive lock without spawning a process > for instance... I agree. At Schrodinger, we added two functions to our version of sqlite3: /* The sqlite3 APIs to get file descriptors fo the open files */ int sqlite3_get_database_file_fd( sqlite3* sqlite3_db_ptr ); int sqlite3_get_journal_file_fd( sqlite3* sqlite3_db_ptr ); This was done to prevent the open files from being inherited by forked child processes, using fcntl(fd, F_SETFD, FD_CLOEXEC), since otherwise those child processes could keep the files open, thereby preventing deletion of the database files (and the directory that contains them) in the parent process. It would be better for us to have similar functions included as part of the standard sqlite interface. --- The database files are kept inside project directories, created by the same client application, to store data about project entries and their properties. In this application, there is expected to be only a single client process accessing the database, and the project is locked by the client to ensure this. Before adding these functions (in order to set the FD_CLOEXEC flag), we had problems with the deletion of scratch (temporary) projects or user deletion of projects, because child processes launched in the background (such as calculation job processes or browsers for online help) would by default inherit all open files. The database files are open essentially the entire time that the project is open, because we maintain an open transaction at all times (except for commit or rollback of changes to the project data) to improve performance and to handle single-level undo of data modifications (in the project, and in the application state). --- Andy Spencer <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
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 EXCLUSIVE" statement and then copy the database file. - Original Message - From: "Cyrus Durgin" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> 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 I'm 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 for this purpose? The docs are a bit sparse regarding their intended purposes. 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, what is the proper way to copy a database using the C API without introducing a 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] -
RE: [sqlite] how to get file handle from sqlite3 object?
> There is a better workaround: get the code from the .dump command of sqlite3 > utility and use it... > it creates a fresh copy of your database like using > > sqlite3 dbold .dump | sqlite3 newdb (not sure about the syntax, there´s a > example of this > case on internet) This will always work and is safe, but it's very slow on large databases with tables with many indexes. You also lose page_size and other pragma settings on your database. > I think a possible solution is to lock the database with a "BEGIN EXCLUSIVE" > statement and then copy the database file. This will also work on UNIX - but only if the file copy is done via a different(!!) UNIX process. If you try to make the copy via the same process - even by open()ing a new file descriptor while the sqlite3 database is in use, you can end up with a corrupt database. The only safe way to perform an exclusive-lock-copy-db-file-in-same-process is to actually use the same file descriptor of an already open database, perform read()s on that fd (and obviously not close() it). So if you wish to do such a thing, you'd either need to expose the file descriptor of the database, or have sqlite provide a new API function to safely copy a database that has active sqlite3 connection(s). See: Ticket 2665: Dissapearing exclusive lock when DB is copied... http://www.sqlite.org/cvstrac/tktview?tn=2665 "2007-Sep-25 18:32:06 by drh: On unix, when you close a file, all locks on that file held by the same process are cleared - even locks that were created by separate file descriptors. You are probably closing the file at the conclusion of your copy, which is clearing the locks." Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] how to get file handle from sqlite3 object?
There is a better workaround: get the code from the .dump command of sqlite3 utility and use it... it creates a fresh copy of your database like using sqlite3 dbold .dump | sqlite3 newdb (not sure about the syntax, there´s a example of this case on internet) -Original Message- From: Ronny Dierckx [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 10 de outubro de 2007 13:55 To: sqlite-users@sqlite.org Subject: Re: [sqlite] how to get file handle from sqlite3 object? I think a possible solution is to lock the database with a "BEGIN EXCLUSIVE" statement and then copy the database file. - Original Message - From: "Cyrus Durgin" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> 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 I'm > 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 for > this purpose? The docs are a bit sparse regarding their intended > purposes. > > 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, >> what >> > is the proper way to copy a database using the C API without >> > introducing >> a >> > 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] -
Re: [sqlite] how to get file handle from sqlite3 object?
Agreed - it seems like this would be useful enough functionality that I'm 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 for this purpose? The docs are a bit sparse regarding their intended purposes. 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, > what > > is the proper way to copy a database using the C API without introducing > a > > race condition? > > > > On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote: > > > >>>-Original Message- > >>>From: Cyrus Durgin [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, October 09, 2007 5:02 PM > >>>To: sqlite-users@sqlite.org > >>>Subject: [sqlite] how to get file handle from sqlite3 object? > >>> > >>>i'm wondering if there's a "standard" way to get an open file > >>>handle from an > >>>sqlite3 pointer using the C API. anyone know? > >>> > >> > >>There's no public way to get this, nor should there be. The internal > >>implementation of the database should be kept separate from the logical > >>API > >>to access it. Such a function would muddy the water between > >>implementation > >>and interface and hamper the ability to change the implementation > without > >>changing the interface. > >> > >>Not all filesystems would be able to return one, nor could it guarantee > >>that > >>the database is in fit state for someone to fiddle with its internal > >>handle. > >>Furthermore, it could not be guaranteed that once a caller obtained the > >>handle that the caller might then do something damaging to it or alter > its > >>state. > >> > >>Such a function definitely falls into the BAD IDEA category, IMO. > >> > >>Robert > >> > >> > >> > >> > > >>- > >>To unsubscribe, send email to [EMAIL PROTECTED] > >> > > >>- > >> > >> > > > > > > > > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > > - > > -- Cyrus. <[EMAIL PROTECTED]>
Re: [sqlite] how to get file handle from sqlite3 object?
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, what is the proper way to copy a database using the C API without introducing a race condition? On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote: -Original Message- From: Cyrus Durgin [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 09, 2007 5:02 PM To: sqlite-users@sqlite.org Subject: [sqlite] how to get file handle from sqlite3 object? i'm wondering if there's a "standard" way to get an open file handle from an sqlite3 pointer using the C API. anyone know? There's no public way to get this, nor should there be. The internal implementation of the database should be kept separate from the logical API to access it. Such a function would muddy the water between implementation and interface and hamper the ability to change the implementation without changing the interface. Not all filesystems would be able to return one, nor could it guarantee that the database is in fit state for someone to fiddle with its internal handle. Furthermore, it could not be guaranteed that once a caller obtained the handle that the caller might then do something damaging to it or alter its state. Such a function definitely falls into the BAD IDEA category, IMO. Robert - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
Two approaches - use sqlite, or use OS code. Use proper filesystem synchronization as appropriate for the given OS & filesystem, where you guarantee that your db copy is the only one that holds an exclusive lock. Then do the file copy and release the lock. The better approach, IMHO would be to create a new database with the same schema, attach it to the existing db instance, and copy over the data using transactions, then detach it. This way, you've got access to the original database and the database copy has a consistent, thread-safe view of the data in the original. Additionally, my guess would be the copy would be vacuumed, which if you're using the copy for backup purposes is great since it saves on disk space. Cyrus Durgin wrote: Maybe it would help to state my use case: without this functionality, what is the proper way to copy a database using the C API without introducing a race condition? On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote: -Original Message- From: Cyrus Durgin [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 09, 2007 5:02 PM To: sqlite-users@sqlite.org Subject: [sqlite] how to get file handle from sqlite3 object? i'm wondering if there's a "standard" way to get an open file handle from an sqlite3 pointer using the C API. anyone know? There's no public way to get this, nor should there be. The internal implementation of the database should be kept separate from the logical API to access it. Such a function would muddy the water between implementation and interface and hamper the ability to change the implementation without changing the interface. Not all filesystems would be able to return one, nor could it guarantee that the database is in fit state for someone to fiddle with its internal handle. Furthermore, it could not be guaranteed that once a caller obtained the handle that the caller might then do something damaging to it or alter its state. Such a function definitely falls into the BAD IDEA category, IMO. Robert - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
Maybe it would help to state my use case: without this functionality, what is the proper way to copy a database using the C API without introducing a race condition? On 10/9/07, Robert Simpson <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > From: Cyrus Durgin [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 09, 2007 5:02 PM > > To: sqlite-users@sqlite.org > > Subject: [sqlite] how to get file handle from sqlite3 object? > > > > i'm wondering if there's a "standard" way to get an open file > > handle from an > > sqlite3 pointer using the C API. anyone know? > > > > There's no public way to get this, nor should there be. The internal > implementation of the database should be kept separate from the logical > API > to access it. Such a function would muddy the water between > implementation > and interface and hamper the ability to change the implementation without > changing the interface. > > Not all filesystems would be able to return one, nor could it guarantee > that > the database is in fit state for someone to fiddle with its internal > handle. > Furthermore, it could not be guaranteed that once a caller obtained the > handle that the caller might then do something damaging to it or alter its > state. > > Such a function definitely falls into the BAD IDEA category, IMO. > > Robert > > > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > > - > > -- Cyrus. <[EMAIL PROTECTED]>
Re: [sqlite] how to get file handle from sqlite3 object?
--- Cyrus Durgin <[EMAIL PROTECTED]> wrote:
> i'm wondering if there's a "standard" way to get an open file handle from an
> sqlite3 pointer using the C API. anyone know?
Patch below implements getting a file descriptor for a UNIX database
using the existing sqlite3 API function sqlite3_file_control() and a
new non-standard option SQLITE_FCNTL_FD. If the function succeeds
SQLITE_OK is returned.
Sample usage:
// The second parameter to sqlite3_file_control is the database alias.
// "main" is the default database alias.
// If you ran the command "attach database 'test.db' as 'whatever';",
// then "whatever" would be the second parameter.
int fd = -1;
if (SQLITE_OK == sqlite3_file_control(db, "main", SQLITE_FCNTL_FD, )){
printf("\nSQLITE_FCNTL_FD = %d\n", fd);
}
Patch is OS dependent. To add Windows support, change winFileControl in
os_win.c in the same way as unixFileControl below.
_
Index: src/os_unix.c
===
RCS file: /sqlite/sqlite/src/os_unix.c,v
retrieving revision 1.169
diff -u -3 -p -r1.169 os_unix.c
--- src/os_unix.c 20 Sep 2007 10:02:54 - 1.169
+++ src/os_unix.c 10 Oct 2007 03:51:41 -
@@ -2018,6 +2018,10 @@ static int unixFileControl(sqlite3_file
*(int*)pArg = ((unixFile*)id)->locktype;
return SQLITE_OK;
}
+case SQLITE_FCNTL_FD: {
+ *(int*)pArg = ((unixFile*)id)->h;
+ return SQLITE_OK;
+}
}
return SQLITE_ERROR;
}
Index: src/sqlite.h.in
===
RCS file: /sqlite/sqlite/src/sqlite.h.in,v
retrieving revision 1.266
diff -u -3 -p -r1.266 sqlite.h.in
--- src/sqlite.h.in 3 Oct 2007 20:15:28 - 1.266
+++ src/sqlite.h.in 10 Oct 2007 03:51:42 -
@@ -557,6 +557,7 @@ struct sqlite3_io_methods {
** is defined.
*/
#define SQLITE_FCNTL_LOCKSTATE1
+#define SQLITE_FCNTL_FD 64
/*
** CAPI3REF: Mutex Handle
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
RE: [sqlite] how to get file handle from sqlite3 object?
> -Original Message- > From: Cyrus Durgin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 09, 2007 5:02 PM > To: sqlite-users@sqlite.org > Subject: [sqlite] how to get file handle from sqlite3 object? > > i'm wondering if there's a "standard" way to get an open file > handle from an > sqlite3 pointer using the C API. anyone know? > There's no public way to get this, nor should there be. The internal implementation of the database should be kept separate from the logical API to access it. Such a function would muddy the water between implementation and interface and hamper the ability to change the implementation without changing the interface. Not all filesystems would be able to return one, nor could it guarantee that the database is in fit state for someone to fiddle with its internal handle. Furthermore, it could not be guaranteed that once a caller obtained the handle that the caller might then do something damaging to it or alter its state. Such a function definitely falls into the BAD IDEA category, IMO. Robert - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
--- Cyrus Durgin <[EMAIL PROTECTED]> wrote: > i'm wondering if there's a "standard" way to get an open file handle from an > sqlite3 pointer using the C API. anyone know? No such function exists, but it would be a useful addition to the API. Copying the database during an exclusive lock without spawning a process for instance... http://www.sqlite.org/cvstrac/tktview?tn=2665 Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how to get file handle from sqlite3 object?
Can you please clarify why this would be needed? Sqlite databases are opened by name, thereby you can use standard OS or stdlib functions to open the same file with a different handle. Cyrus Durgin wrote: i'm wondering if there's a "standard" way to get an open file handle from an sqlite3 pointer using the C API. anyone know? - To unsubscribe, send email to [EMAIL PROTECTED] -
