Hi,
The porting is done in little tricky way due to limited support from
underlying platform.
Ported code does not completely follow WINDOWS. it is WINDOWS + WINCE
configuration.
Porting is done as below.
*Step 1.* Main macros defnined in the source include:
#define SQLITE_DEBUG 0
#define SQLITE_OS_OTHER 1
#define SQLITE_MUTEX_OTHER_OS 1
#define SQLITE_CORE 1
#define SQLITE_AMALGAMATION 1
SQLITE_OS_OTHER is same as SQLITE_OS_WIN
*Step 2.* SQLITE_OS_WINCE is not defined but isNT() is defined as 1.
#define isNT() 1
Here is the code snippet of otherOsClose() API for your reference.
====================================================
#define MX_CLOSE_ATTEMPT 3
static int otherOsClose(sqlite3_file *id){
int rc, cnt = 0;
otherOsFile *pFile = (otherOsFile*)id;
assert( id!=0 );
assert( pFile->pShm==0 );
OSTRACE2("CLOSE %d\n", pFile->h);
do{
rc = CloseHandle(pFile->h);
/* SimulateIOError( rc=0; cnt=MX_CLOSE_ATTEMPT; ); */
}while( rc==0 && ++cnt < MX_CLOSE_ATTEMPT && (Sleep(100), 1) );
#if SQLITE_OS_WINCE
#define WINCE_DELETION_ATTEMPTS 3
winceDestroyLock(pFile);
if( pFile->zDeleteOnClose ){
int cnt = 0;
while(
DeleteFileW(pFile->zDeleteOnClose)==0
&& GetFileAttributesW(pFile->zDeleteOnClose)!=0xffffffff
&& cnt++ < WINCE_DELETION_ATTEMPTS
){
Sleep(100); /* Wait a little before trying again */
}
free(pFile->zDeleteOnClose);
}
#endif
OSTRACE3("CLOSE %d %s\n", pFile->h, rc ? "ok" : "failed");
OpenCounter(-1);
return rc ? SQLITE_OK : SQLITE_IOERR;
}
============================================================
With configuration steps 1 and 2 as mentioned above, will there be any
problems?
Since SQLITE_OS_WINCE is not defined as 1, the file will not be deleted on
close. I can make some hack to enable pFile->zDeleteOnClose and modify the
ported code to delete the file if pFile->zDeleteOnClose is true without
actually defining macro SQLITE_OS_WINCE.
SQLITE_OS_WINCE can not be enabled since it requires winceLocks to be
implemented which can not be supported at the moment.
Thanks,
Sudha
On Wed, Feb 23, 2011 at 8:14 PM, Shane Harrelson <[email protected]> wrote:
> Hi-
>
> On Windows, SQLite uses the FILE_FLAG_DELETE_ON_CLOSE flag to have
> temporary files automatically deleted after they are closed. WINCE
> doesn't support this flag, so you will see special logic in os_win.c,
> wrapped in #ifdef SQLITE_OS_WINCE, for handling the deletion of these
> files. You mentioned in an earlier post that you had ported to your
> platform based on this code. Could you check that your ported code
> includes this logic?
>
> -Shane
>
> On Wed, Feb 23, 2011 at 9:00 AM, Sudha Venkatareddy <[email protected]>
> wrote:
> > Hi,
> >
> > I referred the link http://www.sqlite.org/cvstrac/tktview?tn=2829
> > it is slightly related to it but the temporary files are created while
> > running VACUUM command.
> > ---------------------------------------------------------------
> > Ticket 2829:
> >
> > This patch seems to fix it (added: SQLITE_OPEN_DELETEONCLOSE):
> >
> > if( flags & (SQLITE_OPEN_TEMP_DB | SQLITE_OPEN_TEMP_JOURNAL
> > - | SQLITE_OPEN_SUBJOURNAL) ){
> > + | SQLITE_OPEN_SUBJOURNAL |
> SQLITE_OPEN_DELETEONCLOSE) ){
> >
> >
> ------------------------------------------------------------------------------
> >
> > The temp files were created in the below call sequence:
> >
> > -----------------------------------------------------------------
> > 62 otherOsOpen() sqlite3.c:123900 0x3afe25bd
> > 61 sqlite3OsOpen() sqlite3.c:15280 0x3af550d0
> > 60 pagerOpentemp() sqlite3.c:39431 0x3af62e70
> > 59 pager_write_pagelist() sqlite3.c:40030 0x3af63a68
> > 58 sqlite3PagerCommitPhaseOne() sqlite3.c:41884 0x3af669ff
> > 57 sqlite3BtreeCommitPhaseOne() sqlite3.c:48993 0x3af72665
> > 56 sqlite3BtreeCommit() sqlite3.c:49083 0x3af728e6
> > 55 sqlite3RunVacuum() sqlite3.c:94735 0x3afcce29
> > 54 sqlite3VdbeExec() sqlite3.c:66384 0x3af961e4
> > 53 sqlite3Step() sqlite3.c:59380 0x3af87b34
> > 52 sqlite3_step() sqlite3.c:59444 0x3af87d6e
> > 51 sqlite3_exec() sqlite3.c:84701 0x3afb86b9
> > ------------------------------------------------------------------
> >
> >
> >
> > Basically there 2 problems associated when i run VACUUM command.
> > Problem 1. Running VACUUM leaves 3 temporary files in the temp directory
> > which are not deleted when main DB is closed.
> > Problem 2. Upon applying VACUUM command on say main DB file MyDb.db , and
> > closing the main DB connection, the size of the main DB file MyDb.db does
> > not change where as one of the temp file(etilqs_*) will actually contain
> the
> > reduced size of the same data as of main DB file.
> >
> > I am not sure if this is the expected behaviour or there is some bug in
> the
> > flow.
> >
> > Please let me know if there is a solution to resolve this issue.
> >
> > Thanks,
> > Sudha
> >
> > On Wed, Feb 23, 2011 at 5:52 PM, Simon Slavin <[email protected]>
> wrote:
> >
> >>
> >> On 23 Feb 2011, at 6:11am, Sudha Venkatareddy wrote:
> >>
> >> > *Actual output: MyDb.db remains size 23KB(size not changes from
> original)
> >> > and creates temporary file etilqs_Hm4RUi6JPXcMZ17 whose data is same
> as
> >> > MyDb.db but the size is reduced to 13KB*
> >>
> >> Your problem is probably related to
> >>
> >> http://www.sqlite.org/cvstrac/tktview?tn=2829
> >>
> >> . It's quite legitimate for your symptoms to occur while the database
> >> handle is still open but you should not be seeing those files after you
> have
> >> closed the connection to the database. Either you are not closing the
> >> database connection properly, or some part of the API you're using is
> not
> >> closing the database connection properly.
> >>
> >> I'm not familiar with how this problem manifests because I don't use
> >> Windows, so I'll leave it up to an expert to tell you if it needs fixing
> >> somehow.
> >>
> >> Simon.
> >> _______________________________________________
> >> sqlite-users mailing list
> >> [email protected]
> >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >>
> > _______________________________________________
> > sqlite-users mailing list
> > [email protected]
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
