From: Joseph C. <jos...@gm...> - 2005-05-17 20:50:27
|
What exactly is the lookup call, how do I trap it and how do I report back what its looking for. I'm creating an FS using FUSE but it hangs at the LOOKUP request. I went through the examples and there is no LOOKUP request there. I did a google search and no real info just an obscure ref found at: http://arg0.net/users/vgough/devel/sulf/Fuse/Reactor.cs But I believe I'm going to have to deal with call. It mainly fails during a symlink operation but I want to know what is going on. What I am trying to do is allow symlinks to be created and have those creations point to the fake file that is generated by my filesystem. This is important since some of the apps require the file to be a symlink and not just a file. But I get into some sort of loop during the LOOKUP operation and it hangs. I can't seem to find any useful docs on this subject and I'm bad at reading the fuse source code, which I tried. Thanks |
From: Valient G. <vg...@po...> - 2005-05-18 07:55:23
|
On Tuesday 17 May 2005 22:50, Joseph Cohen wrote: > What exactly is the lookup call, how do I trap it and how do I report > back what its looking for. > > I'm creating an FS using FUSE but it hangs at the LOOKUP request. I > went through the examples and there is no LOOKUP request there. I did > a google search and no real info just an obscure ref found at: > > http://arg0.net/users/vgough/devel/sulf/Fuse/Reactor.cs That's part of my C# wrapper for FUSE :-). The reason it has a LOOKUP handler but the examples don't is because my wrapper is talking to the kernel directly (a replacement for libfuse). Libfuse handles LOOKUP requests from the kernel as well, but they are turned into getattr() calls in the user filesystem. So if you've provided a getattr() callback, then that should be called by libfuse. You should check your getattr() and symlink() callbacks -- in particular note that fuse callbacks typically return 0 on success and a negative number on failure. For example, for symlink(), the error checking code should look something like this: int myfs_symlink( const char *from, const char *to ) { int res; res = symlink( ... ); if(res == -1) res = -errno; /* negative errno on failure */ else res = 0; /* success */ return res; } regards, Valient |
From: Joshua J. B. <con...@co...> - 2005-05-18 16:23:42
|
Just out of curiosity, what is the difference between LOOKUP and GETATTR? I was noticing they both appear to do roughly the same thing (even though they're handled slightly differently), and I was wondering which gets trigg= ered in what situations. On Wed, May 18, 2005 at 09:55:08AM +0200, Valient Gough wrote: > On Tuesday 17 May 2005 22:50, Joseph Cohen wrote: > > What exactly is the lookup call, how do I trap it and how do I report > > back what its looking for. > > > > I'm creating an FS using FUSE but it hangs at the LOOKUP request. I > > went through the examples and there is no LOOKUP request there. I did > > a google search and no real info just an obscure ref found at: > > > > http://arg0.net/users/vgough/devel/sulf/Fuse/Reactor.cs >=20 > That's part of my C# wrapper for FUSE :-). The reason it has a LOOKUP ha= ndler=20 > but the examples don't is because my wrapper is talking to the kernel=20 > directly (a replacement for libfuse). Libfuse handles LOOKUP requests f= rom=20 > the kernel as well, but they are turned into getattr() calls in the user= =20 > filesystem. >=20 > So if you've provided a getattr() callback, then that should be called by= =20 > libfuse. >=20 > You should check your getattr() and symlink() callbacks -- in particular = note=20 > that fuse callbacks typically return 0 on success and a negative number o= n=20 > failure.=20 >=20 > For example, for symlink(), the error checking code should look something= like=20 > this: >=20 > int myfs_symlink( const char *from, const char *to ) > { > int res; > res =3D symlink( ... ); > if(res =3D=3D -1) > res =3D -errno; /* negative errno on failure */ > else > res =3D 0; /* success */ > return res; > } >=20 >=20 > regards, > Valient >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel >=20 --=20 Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune |
From: Valient G. <vg...@po...> - 2005-05-18 17:43:10
|
On Wednesday 18 May 2005 18:23, Joshua J. Berry wrote: > Just out of curiosity, what is the difference between LOOKUP and GETATTR? > > I was noticing they both appear to do roughly the same thing (even though > they're handled slightly differently), and I was wondering which gets > triggered in what situations. > LOOKUP is sent when the inode number isn't known. GETATTR is sent to find the attributes of a particular inode. So you won't see GETATTR calls for a node unless it has been looked up with LOOKUP. LOOKUP takes <directory inode, child node name> and returns a fuse_entry_out structure which contains the node id of the child (if it exists). A GETATTR takes a node id and returns a fuse_attr_out structure for that node. Both structures contain the various attributes of the file, but they are used at different times. If you are interested in the kernel level communication, you can look in the kernel/fuse_kernel.h header file which shows the structures the FUSE kernel module uses for communicating with user programs (like libfuse). Valient |
From: Joshua J. B. <con...@co...> - 2005-05-18 18:19:42
|
On Wed, May 18, 2005 at 07:43:00PM +0200, Valient Gough wrote: > On Wednesday 18 May 2005 18:23, Joshua J. Berry wrote: > > Just out of curiosity, what is the difference between LOOKUP and GETATT= R? > > > > I was noticing they both appear to do roughly the same thing (even thou= gh > > they're handled slightly differently), and I was wondering which gets > > triggered in what situations. > > >=20 > LOOKUP is sent when the inode number isn't known. GETATTR is sent to fin= d the=20 > attributes of a particular inode. So you won't see GETATTR calls for a n= ode=20 > unless it has been looked up with LOOKUP. >=20 > LOOKUP takes <directory inode, child node name> and returns a fuse_entry_= out=20 > structure which contains the node id of the child (if it exists). A GETA= TTR=20 > takes a node id and returns a fuse_attr_out structure for that node. Bot= h=20 > structures contain the various attributes of the file, but they are used = at=20 > different times. Ahhhh, ok. That makes sense. Thanks. :) > If you are interested in the kernel level communication, you can look in = the=20 > kernel/fuse_kernel.h header file which shows the structures the FUSE kern= el=20 > module uses for communicating with user programs (like libfuse). Yeah, that's what I've been looking at. I have decided I want an Inode-bas= ed interface for my filesystem (which is in C++), hence my question. -- Josh --=20 Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune |
From: Valient G. <vg...@po...> - 2005-05-18 18:55:00
|
On Wednesday 18 May 2005 20:19, Joshua J. Berry wrote: > On Wed, May 18, 2005 at 07:43:00PM +0200, Valient Gough wrote: > > If you are interested in the kernel level communication, you can look in > > the kernel/fuse_kernel.h header file which shows the structures the FUSE > > kernel module uses for communicating with user programs (like libfuse). > > Yeah, that's what I've been looking at. I have decided I want an > Inode-based interface for my filesystem (which is in C++), hence my > question. A small warning -- using the kernel interface isn't as easy as using the interface that libfuse provides.. The kernel interface has changed more often then the libfuse interface, and it isn't as well documented. If you are going to write an interface to the FUSE kernel module, consider that you are writing a replacement for libfuse in addition to your filesystem. I have a C++ filesystem (freshmeat.net/projects/encfs) which uses libfuse. Miklos has added a lot of functionality to the libfuse api lately, so I think I wouldn't gain all that much in moving over to an inode based interface... There's been talk about inode based interfaces on this list before, you might check the archives - I know there had been some work on an inode interface layer. regards, Valient |
From: Joshua J. B. <con...@co...> - 2005-05-18 19:10:11
|
On Wed, May 18, 2005 at 08:54:38PM +0200, Valient Gough wrote: > On Wednesday 18 May 2005 20:19, Joshua J. Berry wrote: > > On Wed, May 18, 2005 at 07:43:00PM +0200, Valient Gough wrote: > > > If you are interested in the kernel level communication, you can look= in > > > the kernel/fuse_kernel.h header file which shows the structures the F= USE > > > kernel module uses for communicating with user programs (like libfuse= ). > > > > Yeah, that's what I've been looking at. I have decided I want an > > Inode-based interface for my filesystem (which is in C++), hence my > > question. >=20 > A small warning -- using the kernel interface isn't as easy as using the= =20 > interface that libfuse provides.. The kernel interface has changed more= =20 > often then the libfuse interface, and it isn't as well documented. If yo= u=20 > are going to write an interface to the FUSE kernel module, consider that = you=20 > are writing a replacement for libfuse in addition to your filesystem. I know. But I'm currently using libfuse, and the path-based API makes thin= gs somewhat more complicated for me. (Each inode is a C++ object ... how do I= know when the OS is done with a given inode and I can release it from my inode c= ache? Plus I have to do lookups starting at the root every single time a user pro= cess accesses the filesystem (well, with the exception of open files in FUSE 2.2= ) ... that's pretty inefficient.) I think in the long run, it will probably be simpler for me to write my cod= e for an inode-based API, and use the FUSE kernel interface directly as a stopgap until an official inode-based API is available. > I have a C++ filesystem (freshmeat.net/projects/encfs) which uses libfuse= =2E =20 > Miklos has added a lot of functionality to the libfuse api lately, so I t= hink=20 > I wouldn't gain all that much in moving over to an inode based interface.= =2E. >=20 > There's been talk about inode based interfaces on this list before, you m= ight=20 > check the archives - I know there had been some work on an inode interfac= e=20 > layer. I've looked, but I never found anything substantial that I could use... per= haps I missed something? I would much prefer to use an API than have to parse kernel messages direct= ly. ;) Thanks. -- Josh --=20 Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune |