Quoth Roger Binns <rog...@rogerbinns.com>, on 2011-02-28 13:03:43 -0800: > On 02/28/2011 12:41 PM, Drake Wilson wrote: > > Back on the original topic, I would rather think a custom VFS sounds > > like the way to go; > > It is technically correct that will work. However it is a *lot* of > maintenance work. > > The custom VFS would be a duplicate of the platform one (lots of code) but > with only a very small number of lines changed.
Perhaps, but DRH in the earlier thread "upstreaming Chromium patches for file handle passing support" wrote: | os_unix.c is very unlikely to change in ways that you care about. It has | not changed in years in ways that would effect you, except for the addition | of new methods to support WAL for the 3.6.23->3.7.0 transition. Such | changes are very uncommon. You can continue to pull in newer versions of | SQLite without having to modify your customized chromium VFS. If you are | ever in doubt about whether or not it is safe to continue to use an old VFS | based on an older os_unix.c, then simply ask. [...] | The only thing that might trip you up is a bug fix in os_unix.c. Those are | very, very uncommon. In fact, I can't call to mind the last time we had any | serious bug in os_unix.c. I'm inclined to believe this nullifies the main argument against forking os_unix.c in the absence of strong evidence to the contrary. Furthermore, another approach if the name<->FD thing is the only requirement would be to retrieve all the original VFS methods at init time (using sqlite3_vfs_find) and only alter a few of them when registering the new one, essentially "subclassing" the VFS. I haven't seen anything that would require changes except ones that are filename-related and easily refactorable into a short stack of local functions plus wrappers for the methods that take a filename argument, but I haven't looked as closely as Pavel, Richard, et al. presumably have. The main tricky case is where POSIX advisory locking requires bogusly keeping earlier file descriptors open, and that's the case if you open the same underlying database file multiple times. Are there comments from the Chromium folks about whether multiple descriptors for the same file might get passed down to the sandboxed process? Could that be reasonably prevented on the parent-link side somehow? ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
