On Thu, May 10, 2012 at 6:58 AM, Jeff Darcy
<address@hidden> wrote:
On Thu, 10 May 2012 15:55:55 +1000
"Ian Latter" <
address@hidden> wrote:
> So, I guess;
> 1) Are all Fuse/FS ops handled by Gluster?
> 2) Where can I find a complete list of the
> Gluster fops, and not just those that have
> been used in existing modules?
structure. When building translators, it can also be convenient to
look at the default_xxx and default_xxx_cbk functions for each fop you
implement. Also, I forgot to mention in my comments on your "hide"
translator that you can often use the default_xxx_cbk callback when you
call STACK_WIND, instead of having to define your own trivial one.
FUSE operations are listed by the fuse_opcode enum. You can check for
yourself how closely this matches our list. They do have a few ops of
their own, we have a few of their own, and a few of theirs actually map
to our xlator_cbks instead of xlator_fops. The points of
non-correspondence seem to be interrupt, bmap, poll and ioctl. Maybe
Csaba can elaborate on what we do (or plan to do) about these.
We might support interrupt sometime. Bmap - probably never. Poll, maybe. Ioctl - depeneds on what type of ioctl and requirement.
> 3) Is it safe to path match on loc_t? (i.e. is
> it fully resolved such that I won't find
> /etc/././././passwd)? This I could test ..
Name/path resolution is an area that has changed pretty recently, so
I'll let Avati or Amar field that one.
The ".." interpretation is done by the client side VFS. Internal path construction does not use ".." and are always normalized. There are new situations where we now support non-absolute paths, but those are for GFID based addressing and ".." does not come into picture there.
Avati