On 28 Feb 2011, at 20:38, Roger Binns wrote: >> Why is it not possible to create a custom VFS for the intended purpose >> and register it for the connections that need it? > > Because that custom VFS would be an almost duplicate of the existing VFS but > with a few key places changed. > > If the changes were at the granularity of the VFS methods then it would be > no problem to "inherit" as needed. Unfortunately they are within - for > example wanting to use the xOpen method but changing only the open() call > within.
I argue that this implies a problem in the Chromium sandbox rather than a problem in the SQLite code. Either the Chromium sandbox does not allow files to be opened at all (in which case you can't have SQLite) or it does. If it does, why is the routine that allows you to do so named something other than open()? If you cannot open files but can ask a supervisor to open files on your behalf, the natural thing to do is to write a routine named open() that invokes the supervisor and give it the semantics of POSIX open(). Similarly for close() stat() and the various locking calls. Not only would this make SQLite work unmodified but it would make the next n things that have a similar issue work for free as well. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
