Various API questions

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Various API questions

Nikolaus Rath
Hello,

I have searched the wiki and documentation carefully, but I couldn't
find any answers to the following questions. If I missed something,
please just give me the pointer. Otherwise I'd be glad if someone
could help me to understand a couple of points:

 - What value should I return for st_dev in getaddr?

 - Which checks are already performed on the arguments of the various
   fuse operations? E.g. do I have to check if the argument of
   readlink is actually a symlink, the argument of readdir a directory,
   or the argument of symlink does not yet exist?

   A quick test told me that all this is checked, but I'd like to be
   sure...
   
 - Do I have to worry about race conditions? E.g. do I have to take
   care that my unlink function cannot be interrupted by an open call
   that recreates the file before it has completely been unlinked?

   Again I suspect that this is handled by the VFS, but I couldn't
   find it in written anywhere...

 - Am I correct that the access() function is never called if I use
   -o default_permissions?

 - Where can I find an explanation of the various parameters that I
   can pass to fuse? In particular I am interested in use_ino,
   readdir_ino which I suspect to be important for me since my
   filesystem has inode numbers. However, I also fail to completely
   understand the effects of direct_io, kernel_cache, auto_cache,
   *_timeout, intr, intr_signal, large_read and modules...


Thanks in advance for any help.


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Fri, 04 Jul 2008, Nikolaus Rath wrote:
> Hello,
>
> I have searched the wiki and documentation carefully, but I couldn't
> find any answers to the following questions. If I missed something,
> please just give me the pointer. Otherwise I'd be glad if someone
> could help me to understand a couple of points:
>
>  - What value should I return for st_dev in getaddr?

The value of st_dev is ignored by fuse.  It's filled in by the kernel
to an "anonymous" device allocated to each fuse filesystem.

>  - Which checks are already performed on the arguments of the various
>    fuse operations? E.g. do I have to check if the argument of
>    readlink is actually a symlink, the argument of readdir a directory,
>    or the argument of symlink does not yet exist?
>
>    A quick test told me that all this is checked, but I'd like to be
>    sure...

Yes, the VFS basically does all checks, so the filesystem just needs
to perform the requested operation.

>  - Do I have to worry about race conditions? E.g. do I have to take
>  care that my unlink function cannot be interrupted by an open call
>  that recreates the file before it has completely been unlinked?
>
>    Again I suspect that this is handled by the VFS, but I couldn't
>    find it in written anywhere...

Yes this is checked too.

>
>  - Am I correct that the access() function is never called if I use
>    -o default_permissions?

No, it's still called for access(2) and for chdir(2).

>  - Where can I find an explanation of the various parameters that I
>    can pass to fuse?

Mount options are documented in README.  I may have been sloppy with
updating that, so if you find an undocumented option, let me know.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

> On Fri, 04 Jul 2008, Nikolaus Rath wrote:
>> Hello,
>>
>> I have searched the wiki and documentation carefully, but I couldn't
>> find any answers to the following questions. If I missed something,
>> please just give me the pointer. Otherwise I'd be glad if someone
>> could help me to understand a couple of points:
>>
>>  - What value should I return for st_dev in getaddr?
>
> The value of st_dev is ignored by fuse.  It's filled in by the kernel
> to an "anonymous" device allocated to each fuse filesystem.
>
>>  - Which checks are already performed on the arguments of the various
>>    fuse operations? E.g. do I have to check if the argument of
>>    readlink is actually a symlink, the argument of readdir a directory,
>>    or the argument of symlink does not yet exist?
>>
>>    A quick test told me that all this is checked, but I'd like to be
>>    sure...
>
> Yes, the VFS basically does all checks, so the filesystem just needs
> to perform the requested operation.
>
>>  - Do I have to worry about race conditions? E.g. do I have to take
>>  care that my unlink function cannot be interrupted by an open call
>>  that recreates the file before it has completely been unlinked?
>>
>>    Again I suspect that this is handled by the VFS, but I couldn't
>>    find it in written anywhere...
>
> Yes this is checked too.

Thanks a lot. I have also added this to the Wiki on
http://fuse.sourceforge.net/wiki/index.php/FuseInvariants


>>  - Am I correct that the access() function is never called if I use
>>    -o default_permissions?
>
> No, it's still called for access(2) and for chdir(2).

Is there a way to pass this on to the "usual" implementations? It
seems silly to be to reimplement this, because my filesystem delivers
completely ordinary uid,gid and mode values.


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Sat, 05 Jul 2008, Nikolaus Rath wrote:
> Thanks a lot. I have also added this to the Wiki on
> http://fuse.sourceforge.net/wiki/index.php/FuseInvariants

Thanks!

> >>  - Am I correct that the access() function is never called if I use
> >>    -o default_permissions?
> >
> > No, it's still called for access(2) and for chdir(2).
>
> Is there a way to pass this on to the "usual" implementations? It
> seems silly to be to reimplement this, because my filesystem delivers
> completely ordinary uid,gid and mode values.

Yes, the 'default_permissions' mount option will do that, and then
->access() will never be called.

Miklos1

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

>>>>  - Am I correct that the access() function is never called if I use
>>>>    -o default_permissions?
>>>
>>> No, it's still called for access(2) and for chdir(2).
>>
>> Is there a way to pass this on to the "usual" implementations? It
>> seems silly to be to reimplement this, because my filesystem delivers
>> completely ordinary uid,gid and mode values.
>
> Yes, the 'default_permissions' mount option will do that, and then
> ->access() will never be called.

Now I'm a bit confused. Above you said that access() *will* be called
for chdir(2) and access(2), even if 'default_permissions' is set. So
what is true now?

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Mon, 07 Jul 2008, Nikolaus Rath wrote:

> Miklos Szeredi <[hidden email]> writes:
> >>>>  - Am I correct that the access() function is never called if I use
> >>>>    -o default_permissions?
> >>>
> >>> No, it's still called for access(2) and for chdir(2).
> >>
> >> Is there a way to pass this on to the "usual" implementations? It
> >> seems silly to be to reimplement this, because my filesystem delivers
> >> completely ordinary uid,gid and mode values.
> >
> > Yes, the 'default_permissions' mount option will do that, and then
> > ->access() will never be called.
>
> Now I'm a bit confused. Above you said that access() *will* be called
> for chdir(2) and access(2), even if 'default_permissions' is set. So
> what is true now?

Sorry, I missed the "if I use -o default_permissions" part in your
original question, so my original answer was of course wrong.
->access() will not be called with 'default_permissions'.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:
> Sorry, I missed the "if I use -o default_permissions" part in your
> original question, so my original answer was of course wrong.
> ->access() will not be called with 'default_permissions'.

Ok, thanks. I'll directly follow up with the next question ;-).

What about open() and "default_permissions"? fuse.h says that "open
should check if the operation is permitted for the given flags". Is
this only valid if default_permissions is *not* specified, or does
open() *always* have to perform this check?

(It'd be nice if that could be clarified in fuse.h)


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Mon, 07 Jul 2008, Nikolaus Rath wrote:
> What about open() and "default_permissions"? fuse.h says that "open
> should check if the operation is permitted for the given flags". Is
> this only valid if default_permissions is *not* specified, or does
> open() *always* have to perform this check?

->open() will be called, but with 'default_permissions' the kernel
will perform all permission checks, so the filesystem doesn't need to
repeat it for any of the fs calls.

> (It'd be nice if that could be clarified in fuse.h)

The mount options are documented in README.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:
> On Mon, 07 Jul 2008, Nikolaus Rath wrote:
>> What about open() and "default_permissions"? fuse.h says that "open
>> should check if the operation is permitted for the given flags". Is
>> this only valid if default_permissions is *not* specified, or does
>> open() *always* have to perform this check?
>
> ->open() will be called, but with 'default_permissions' the kernel
> will perform all permission checks, so the filesystem doesn't need to
> repeat it for any of the fs calls.

Ok, got it. Thanks for the clarification.

>> (It'd be nice if that could be clarified in fuse.h)
>
> The mount options are documented in README.

I read the documentation of default_permissions, but I was still
unsure because for access() the comment in fuse.h explicitly said that
it will not be called if default_permissions is set, while for open it
explicitly said that the check must be performed. Therefore I think
that a change along the lines of ...

--- fuse.h.bak 2008-07-08 13:35:26.000000000 +0200
+++ fuse.h 2008-07-08 13:36:32.000000000 +0200
@@ -142,7 +142,8 @@
  /** File open operation
  *
  * No creation, or truncation flags (O_CREAT, O_EXCL, O_TRUNC)
- * will be passed to open().  Open should check if the operation
+ * will be passed to open().  Unless the 'default_permissions'
+ * mount option is given, open should check if the operation
  * is permitted for the given flags.  Optionally open may also
  * return an arbitrary filehandle in the fuse_file_info structure,
  * which will be passed to all file operations.


..couldn't hurt.


Best,


   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Tue, 08 Jul 2008, Nikolaus Rath wrote:

> I read the documentation of default_permissions, but I was still
> unsure because for access() the comment in fuse.h explicitly said that
> it will not be called if default_permissions is set, while for open it
> explicitly said that the check must be performed. Therefore I think
> that a change along the lines of ...
>
> --- fuse.h.bak 2008-07-08 13:35:26.000000000 +0200
> +++ fuse.h 2008-07-08 13:36:32.000000000 +0200
> @@ -142,7 +142,8 @@
>   /** File open operation
>   *
>   * No creation, or truncation flags (O_CREAT, O_EXCL, O_TRUNC)
> - * will be passed to open().  Open should check if the operation
> + * will be passed to open().  Unless the 'default_permissions'
> + * mount option is given, open should check if the operation
>   * is permitted for the given flags.  Optionally open may also
>   * return an arbitrary filehandle in the fuse_file_info structure,
>   * which will be passed to all file operations.
>
>
> ..couldn't hurt.

Thanks, applied.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Brian Wang-2
Then how are flags like O_TRUNC are handled before open is called?

Thanks

--------------------------------------------------
From: "Miklos Szeredi" <[hidden email]>
Sent: Wednesday, July 09, 2008 11:05 AM
To: <[hidden email]>
Cc: <[hidden email]>
Subject: Re: [fuse-devel] Various API questions

> On Tue, 08 Jul 2008, Nikolaus Rath wrote:
>> I read the documentation of default_permissions, but I was still
>> unsure because for access() the comment in fuse.h explicitly said that
>> it will not be called if default_permissions is set, while for open it
>> explicitly said that the check must be performed. Therefore I think
>> that a change along the lines of ...
>>
>> --- fuse.h.bak 2008-07-08 13:35:26.000000000 +0200
>> +++ fuse.h 2008-07-08 13:36:32.000000000 +0200
>> @@ -142,7 +142,8 @@
>>  /** File open operation
>>  *
>>  * No creation, or truncation flags (O_CREAT, O_EXCL, O_TRUNC)
>> - * will be passed to open().  Open should check if the operation
>> + * will be passed to open().  Unless the 'default_permissions'
>> + * mount option is given, open should check if the operation
>>  * is permitted for the given flags.  Optionally open may also
>>  * return an arbitrary filehandle in the fuse_file_info structure,
>>  * which will be passed to all file operations.
>>
>>
>> ..couldn't hurt.
>
> Thanks, applied.
>
> Miklos
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Wed, 9 Jul 2008, Brian Wang wrote:
> Then how are flags like O_TRUNC are handled before open is called?

Normally, O_TRUNC will invoke ->truncate() first, then ->open().

If '-oatomic_o_trunc' is given, and a recent enough kernel module and
library is used, then ->truncate() will not be called and O_TRUNC will
be passed to ->open().

Recent enough in this case means CVS version of library and
linux-2.6.24.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

> On Wed, 9 Jul 2008, Brian Wang wrote:
>> Then how are flags like O_TRUNC are handled before open is called?
>
> Normally, O_TRUNC will invoke ->truncate() first, then ->open().
>
> If '-oatomic_o_trunc' is given, and a recent enough kernel module and
> library is used, then ->truncate() will not be called and O_TRUNC will
> be passed to ->open().
>
> Recent enough in this case means CVS version of library and
> linux-2.6.24.

Here's a patch to update the documentation.

diff -u -b -r1.130 fuse.h
--- include/fuse.h 9 Jul 2008 17:05:01 -0000 1.130
+++ include/fuse.h 12 Jul 2008 17:13:32 -0000
@@ -141,12 +141,18 @@
 
  /** File open operation
  *
- * No creation, or truncation flags (O_CREAT, O_EXCL, O_TRUNC)
- * will be passed to open().  Unless the 'default_permissions'
- * mount option is given, open should check if the operation
- * is permitted for the given flags.  Optionally open may also
- * return an arbitrary filehandle in the fuse_file_info structure,
- * which will be passed to all file operations.
+ * No creation (O_CREAT, O_EXCL) and by default also no
+ * truncation (O_TRUNC) flags will be passed to open(). If an
+ * application specifies O_TRUNC, fuse first calls truncate()
+ * and then open(). Only if 'atomic_o_trunc' has been
+ * specified and kernel version is 2.6.24 or later, O_TRUNC is
+ * passed on to open.
+ *
+ * Unless the 'default_permissions' mount option is given,
+ * open should check if the operation is permitted for the
+ * given flags. Optionally open may also return an arbitrary
+ * filehandle in the fuse_file_info structure, which will be
+ * passed to all file operations.
  *
  * Changed in version 2.2
  */



Best,


   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Various API questions

Miklos Szeredi
On Sat, 12 Jul 2008, Nikolaus Rath wrote:

> Miklos Szeredi <[hidden email]> writes:
> > Normally, O_TRUNC will invoke ->truncate() first, then ->open().
> >
> > If '-oatomic_o_trunc' is given, and a recent enough kernel module and
> > library is used, then ->truncate() will not be called and O_TRUNC will
> > be passed to ->open().
> >
> > Recent enough in this case means CVS version of library and
> > linux-2.6.24.
>
> Here's a patch to update the documentation.

Applied this one as well.  Thanks much.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel