> -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Jan Nijtmans > Sent: 01 September 2014 12:29 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？ > > 2014-09-01 13:04 GMT+02:00 Andy Ling <andy.l...@quantel.com>: > > Although this doesn't feel right having to keep extending the list of error > codes that are checked. > > I'm not sure what else can be done though. Maybe some compile options > that let you choose. > > Here is a list of possible error-codes I found: > > <http://www.vxdev.com/docs/vx55man/vxworks/errno/errnoNumList.html > >
That list is from an older version of vxWorks (5.5). So some things have changed slightly. > > The value 13 is listed here as EACCES, I really doubt this one > should be added: If there really is an access problem, I > think that shouldn't be masked. > That code is still as listed. I suspect the problem is vxWorks can't tell the difference between a file not there and not being able to access the file. Although see later... > There are two entries that end with _FILE_NOT_FOUND, the other one is: > 1310723 0x140003 S_rt11FsLib_FILE_NOT_FOUND > This suggests that for VxWorks an additional check for 0x140003 > might work if you use the rt11 filesystem (whatever that is .....) > rt11 is not supported any longer. It harks back to the days of the LSI11 and DEC. rt11 was the OS DEC used then. It was a bit like a cut down version of VMS. > Other possible candidates: > 2686989 0x29000d S_netDrv_NO_SUCH_FILE_OR_DIR > 2949130 0x2d000a S_nfsDrv_NO_SUCH_FILE_OR_DIR > 7602186 0x74000a S_cdromFsLib_NO_SUCH_FILE_OR_DIRECTORY > They are still current. vxWorks now includes the TrueFlashFilingSystem which has the error code 13303810 0xcb0002 S_tffsLib_FILE_NOT_FOUND I have done some more investigation accessing the host file system. First, running unlink from the command line. Calling unlink for a file that exists works correctly. It deletes the file and returns OK. Calling unlink for a file that doesn't exist returns error and sets errno to EACCES. So this may be a bug or vxWorks may not be able to tell when talking over a network. If I get time I will put in a call to WindRiver to see what the official line is. So I added the check in unixDelete for errno 13 to see what happens. The open does create a database file on my host PC. The create table still fails with a disk I/O error, but it gets a bit further. I've added a print in unixLogError and it prints the following....... os_unix.c:27830: (35) full_fsync(/tgtsvr/testdb.sql-journal) - (1034) The 1034 on the end is errno. So it is failing in unixSync. It has created the testdb.sql-journal file and it is 512 bytes long. So I suspect things are working, but the error checks don't think they are. At this point I probably need more help to save me wasting too much time. Personally I'm not sure how much effort needs to be put into this if it is only the host file system that is a problem. Most vxWorks systems would only be using the host filing system during development. Regards Andy Ling _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
