From: Jay B. <jay...@gm...> - 2012-06-12 16:54:51
|
Yeah, looking into it more (sorry, I'm a newb), it appears getAttr sends an inode back to the kernel, so that's necessary in some form. Your FsNode implementation had methods Inode() and SetInode(). Are those to be implemented as super basic setter/getters, i.e., I don't have to construct a new Inode object when Inode() is called and I don't yet have one set? In that case, I don't have a dependency on Inode and can just provide a service implementation of FsNode like you said. On Tue, Jun 12, 2012 at 12:47 PM, Han-Wen Nienhuys <ha...@gm...>wrote: > On Tue, Jun 12, 2012 at 1:28 PM, Jay Booth <jay...@gm...> wrote: > > Reading into it a little more, it seems as if updating Inode to be an > > interface is the way to go. I'll send you a pull request on go-fuse if > that > > approach works out? > > It's already there; it's called FsNode. > > Have a look at one of the examples that use either PathFileSystem (see > eg. fuse/loopback.go) or NodeFileSystem (see eg. fuse/memnode.go); I > think it will be elucidating. > > >> RE: RawFileSystem vs Node/Path, forgive me if I'm misunderstanding, but > >> you disclaimed the Path file system as having some race conditions, > while > >> the Node version has a dependency on fuse.Inode, which has a number of > >> private variables, notably "children" that seem to assume everything is > >> available on the local machine. This model breaks down on the networked > >> implementation I was envisioning, although it would probably work fine > if > >> Inode were an interface rather than a struct. > > The Inode structure has nothing to do with networked vs. local > machine. It's simply a mirror of the data that the kernel keeps in > the VFS; you would have it too for an implementation of -say- NFS. > libfuse has a similar structure (see fuse/lib/fuse.c, struct node). > > -- > Han-Wen Nienhuys - ha...@xs... - http://www.xs4all.nl/~hanwen > |