Re: [AVFS] [fuse-devel] virtual mountpoints (was: AVFS (but not only) + FUSE : access() returns W_OK, but opening r+ fails)

On 5/2/07, Miklos Szeredi <[email protected]> wrote:
> The union mount concept could enable such virtual mountpoints:
>
>   http://lkml.org/lkml/2007/4/17/150

Yeah, I was just reading about it this afternoon (I'm a few days
behind with the LKML :D). But although the VMP feature could be
implemented through union mount, there are a few things about the
union mount I don't like, although I do see the benefits of such a
powerful mechanism.

> But I'm not sure either.  I think I'd prefer a solution where there
> are no extra files in the filesystem, but one could interpret files as
> directories:
>
>   somefile.txt.gz/extract
>
> and
>
>   foobar.tar.gz/dir/subdir/file
>
> These would be very natural interfaces, without having the filesystem
> cluttered with virtual mountpoints.

Keep in mind that there might be multiple different approaches to
considering any particular file as directory ... for example, if the
file.gz/contents virtual content refers to the actual file for a .gz,
what does a file.tar.gz/contents refer to? The .tar or the contents of
the .tar? You might want to have both accessible, how do you define
the semantics for it?

> Of course I don't know how many applications would break due to this
> (not many I hope), or how many applications assume that a file with
> S_IFREG mode cannot be opened as a directory (probably quite a few).

I assume you want them to act as directories when opened as such, but
only report S_IFREG, right? Because if they reported S_IFREG | S_IFDIR
they would appear as sockets ....

But then, how would an app know if there is a virtual directory
available to open that file as a directory? Just trying to open the
file as directory first and then as file, regardless of what is
reported?

> I'd really prefer if we didn't need _new_ interfaces.  I believe that
> even if some applications will need to be modified to be able to use
> this feature, the filesystem interface itself shouldn't need to be
> modified.

I think we need new interfaces anyway, if not else to select which
provider to use to access the files as directory, for example. And
once we do, we might as well just provide the VMP feature, which can
be designed in a way that would make these information available to
userspace without requiring userspace changes.


-- 
Giuseppe "Oblomov" Bilotta

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/