On Wed, Sep 1, 2010 at 10:20 PM, Max Vlasov <max.vla...@gmail.com> wrote:
>> I wonder whether it would be possible to extend the VFS in a way that would
>> make our use case possible (transferring a file handle over process
>> boundary). Please note that we do it on all platforms. On POSIX we pass an
>> integer file descriptor, and on Windows we pass a HANDLE.
>>
>>
> I used vfs for encryption, but there were not so many changed so I may be
> wrong, but ...
>
> It seems that a filename is known entity for vfs implementation, but for
> sqlite level is an abstraction (except for adding sub-extensions for special
> files). So you could fully replace vfs with yours and invent your own
> semantic and recognize it when file open request goes to you, for example
> for opening main db file ("filehandle:1234"). In this case you probably will
> get a request for journal like "filehandle:1234.db-journal" and this would
> mean that you should create some place you prefer a temporal file. I know it
> looks a little stange, but can someone confirm this approach at least works?I was going to suggest that, too, but it doesn't really resolve the problem, it just shifts it around. When the module tries to open(2) or unlink(2) the handle, it won't work because it's not a real file. If those functions could be overriden without modifying anything else, then they could be passed across to a broker ... but in that case you could just use the original path directly rather than encoding things. Basically this code wants to have separate abstractions for handling paths versus handling file handles. Actually ... on Linux the file descriptor could be setup and then you could rewrite the pathname to open the fd in /proc. Obvious issues with that for unlink(), but maybe that could be worked around by using a persistent journal file. I don't think OSX or Windows have a similar abstraction which could be used directly, though. I kind of wonder if something like sqlite/ext/async couldn't be used, completely delegating everything to the broker. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
