> > > 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
