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

> > 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?

For example:

a)  file.gz/extract                (file)
b)  file.gz/gunzip                 (same as a)
c)  file.tar/extract               (contents of archive)
d)  file.tar/untar/                (same as c)
e)  file.tar.gz/gunzip             (file.tar)
f)  file.tar.gz/extract/           (contents of archive)
g)  file.tar.gz/gunzip/untar/      (same as f)

Note, g) is not a special case, it's just applying the same rule
recursively.

> > 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 ....

A single object can only have a single type.

However 'file.gz' could be a regular file, while 'file.gz/' could be a
directory.  Although again, I'm not sure if this is what we want.

But we should definitely be able to do opendir("file.gz/") and get a
listing without any problems.  Possibly just opendir("file.gz").  Also
we should be able to do stat("file.gz/extract", ...).

So the only problematic case is stat("file.gz/", ...).  I think it
would be logical to make that S_IFDIR, but I'm unsure of the
consequences.

> 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?

Possibly _every_ file could be viewed as a directory.  This was also
proposed as a better alternative to the *xattr() interface.

> > 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.

Well, if we have new interfaces, we definitely do require userspace
changes.  If we don't have new interfaces, then we may or may not
require userspace changes, depending on how well the new functionality
fits into what the applications expect.

Miklos

-------------------------------------------------------------------------
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/