> > > Please try the patch at > > > > http://www.sqlite.org/src/info/b0f6b91f36b503d8ba8d5257bb194f8c1afb483 > > > 3 and > > > see if that fixes the problem. > > > > > > > I think that fixes unixDelete. Running on the vxWorks dosFs disk > > everything works as before. > > > > If I use the host filing system, then I think the delete of the > > non-existent file works, but it then fails in unixSync followed by a fail > > in unixDelete > > > > os_unix.c:27830: (35) full_fsync(/tgtsvr/testdb.sql-journal) - (1034) > > > > > Error code 35 is ENOTSUP - fsync is apparently not supported on your > filesystem. >
I have asked WindRiver about the various issues we have seen and their initial response was... An errno of EACCES is set by the hostFS and unfortunately it’s not aligned with POSIX errno. I have suggested to our developers to update that and it’s tracked internally as VXW6-83401 but the request will be considered an enhancement and the decision will be taken later in time when the product management team will decide to implement it. The fsync is indeed not supported on hostFS so the error is expected. Because the target server connection is mostly used for debugging sessions implementing POSIX API is not in plan. I did query whether fsync is just "unnecessary" and whether it could be made a no-op that just returned OK. So far I haven't had a response. I did wonder whether the ENOTSUP error could be ignored for vxWorks. It seems vaguely reasonable that if fsync is not supported it isn't needed so SQLite could just ignore the error. I did complain to WindRiver that this mess of differences between filing systems makes writing portable code very difficult. Again, I haven't had a reply. Regards Andy Ling _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users