I don't know. The standard debug doesn't print the name, so I will have to add 
something tomorrow.

I can tell you the name of the database file is /ata0:3/testdb.sql and it gets 
created.

It is possible things are working. It is just that the sqlite3_exec is not 
returning SQLITE_OK, so I give up and print an error.

I wonder if before the check was added to unixDelete all unlink errors were 
ignored. So it would have worked just fine and you wouldn't have known it was 
trying to delete files that didn't exist.

I will investigate further tomorrow and let you know the file names.

Regards

Andy Ling

________________________________
From: drhsql...@gmail.com [drhsql...@gmail.com] on behalf of Richard Hipp 
[d...@sqlite.org]
Sent: 12 August 2014 19:15
To: Andy Ling
Cc: General Discussion of SQLite Database; 王庆刚
Subject: Re: [sqlite] HELP sqlite3 used in vxworks has someproblem?

What is the name of the file that SQLite is trying to delete but which does not 
exist?  And what is the name of the corresponding database file?  The name of 
the file that fails unlink() will give us a big clue about what is going wrong.


On Tue, Aug 12, 2014 at 2:13 PM, Richard Hipp 
<d...@sqlite.org<mailto:d...@sqlite.org>> wrote:



On Tue, Aug 12, 2014 at 2:00 PM, Andy Ling 
<andy.l...@quantel.com<mailto:andy.l...@quantel.com>> wrote:
Because the file doesn't exist. I assume because this is a brand new database 
the file hasn't been created yet.

I did debug this originally, but I don't remember the file it is trying to 
delete. It definitely didn't exist though.

To some extent it doesn't really matter. The unixDelete function on vxWorks 
with dosFs is broken for files that don't exist, so some change is needed.

That check to ignore the error when trying to delete a file that does not exist 
- that check was only added less than 2 years ago, 2012-11-10.  So for the 
first 8 years of its history, billions of instances of SQLite3 got along fine 
without that check.  This is not surprising since an attempt to delete a file 
that does not exist should only come up in very rare circumstances.

So we can update the unixDelete routine for that.

But, the fact that your build of SQLite does not work *at all* without such a 
change suggests that there are other problems - problems that are being masked, 
but not resolved, by the unixDelete change.  I'm trying figure out what those 
other problems are.



--
D. Richard Hipp
d...@sqlite.org<mailto:d...@sqlite.org>



--
D. Richard Hipp
d...@sqlite.org<mailto:d...@sqlite.org>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to