open() should allow to set direct_io

[GoogleCodeExporter]

Currently, the open() operation has no way to set the direct_io flag,
because it only gets the file handle rather than the whole struct
fuse_file_info.

Original issue reported on code.google.com by Nikolaus@rath.org on 3 Jun 2009 at 6:23

[GoogleCodeExporter]

The fix in revision 16 seems okay to me. Just one small thing: For consistency,
opendir() should probably also get the whole file_info structure if raw_fi is 
set.

(Sorry for opening this bogus issue. I first had some objections to the fix, 
but when
I thought about it in more detail I realized that I was wrong).

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 6:32

[GoogleCodeExporter]

Currently the raw_fi flag ignores the *dir methods that handle directories. Is 
there a use getting the whole 
fuse_file_info in these methods? If the answer is yes, I will add support for 
these methods too. 

Original comment by verigak on 3 Jun 2009 at 7:42

[GoogleCodeExporter]

I don't have any use in mind, I was just suggesting it for the sake of 
consistency,
so that the two open* functions behave similar.

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 9:34

[GoogleCodeExporter]

I just noted that if raw_fi is set, the filler method may be called repeatedly 
even
if it has returned != 0 because the buffer is full. I think it would be 
sensible to
check the return value and break the loop if a nonzero return value is 
encountered.

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 9:36

[GoogleCodeExporter]

That makes sense, what error is more appropriate to return in that case?

Original comment by verigak on 3 Jun 2009 at 9:55

• Changed state: Accepted

[GoogleCodeExporter]

As I understand it, you should not return any error since readdir() succeeded 
in what
it was expected to do: fill the buffer until it is full. Since filler() 
(hopefully)
transmitted the information that there still entries left, readdir() will be 
called
again with the offset of the remaining entries.

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 10:10

[GoogleCodeExporter]

Yes but readdir returned elements that were ignored. It's clearly an error.

Original comment by verigak on 3 Jun 2009 at 10:57

[GoogleCodeExporter]

I'm afraid I don't understand. Ignored by whom or what?

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 11:02

[GoogleCodeExporter]

Let's say that readdir returns a list of 10 items (tuples) and at item 5 filler 
returns != 0. If the loop breaks there 
and returns success then the last 5 items would have been ignored.

Original comment by verigak on 3 Jun 2009 at 11:06

[GoogleCodeExporter]

Yes, ignored by the *calling* function. Why is that an error? If the calling 
function
decides that it needs only the first 5 items, then why should itself return an 
error?
It succeeded in everything it wanted to do.

Original comment by Nikolaus@rath.org on 3 Jun 2009 at 11:12

[GoogleCodeExporter]

OK you have a point. I will fix it. Thanks!

Original comment by verigak on 3 Jun 2009 at 11:24

[GoogleCodeExporter]

Fixed in rev. 18

Original comment by verigak on 9 Jun 2009 at 4:12

• Changed state: Fixed