[Freedombox-discuss] InDisk -- does this technology exist in open source?
The FUSE ("filesystem in userspace") library/module is implemented in
many/most *NIX operating systems, and would allow a specific on-the-fly
virtual file access like you describe to be implemented in a popular
programming language (bindings for python, ruby, etc). "Classic" FUSE
examples include reading and editing Wikipedia articles as files, storing
files as Gmail attachments, logging of filesystem access, etc.
UNIX has has always been about "any/everything as a file", and the plan9
operating system took this even further. There are many, many specific-
and general-purpose "vritual file system" hacks (such as
files-as-directories, nested mounting, ramdisk mounting, the proc (process
information) and sys (system/kernel information) filesystems, the device
filesystem, etc), FUSE is just the most recent incarnation/library. The
pizza-bilities are endless!
On Wed, 30 May 2012, Rick C. Hodgin wrote:
> The key point is assembling files which are presented to the app as files,
> but after requesting them from different sources over the net. The data also
> doesn't have to be in the literal file format that's presented to the user.
> Suppose I access an overview.ods spreadsheet file on my K: drive (or
> /dev/whatever). That file does not physically exist, but through InDisk is a
> logical file that assembles data from a MySQL database somewhere, queries
> whatever it's programmed to through the setup, and prepares the ods
> spreadsheet file on-the-fly when it's requested. This allows the calling app
> to receive a file as it was designed to do, but no longer directly from a
> regular storage or network source. It now gets an assembled file which
> presents as a real file, but all reads/writes/locks/unlocks/etc go through
> the InDrive layer, which then issues appropriate SQL updates back to the
> server, or if it's on another format, possibly git push's or whatever.
> Does Linux/UNIX currently allow that as a generic virtual file system
> Best regards,
> Rick C. Hodgin