FUSE not respecting FileInfo's keep_cache(false)

[lynaghk]

First off---thanks for releasing this project and taking the time to put together a few simple examples.
It's exactly what I need and has been great to use thus far.

I need my code to be executed every time something tries to read a file; what's the proper way to tell FUSE not to cache reads?

According the the FUSE docs (http://fuse.sourceforge.net/doxygen/structfuse__file__info.html) I should be able to set the file info stuct to have keep_cache = 0 in the filesystem's open call.
I tried adding this to the included HelloFS example:

@Override
public int open(final String path, final FileInfoWrapper info)
{
    info.keep_cache(false);
    return 0;
}    

but the file content is still cached.
cating the file gives:

Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS getattr
INFO: [/hello.txt] Method succeeded. Result: 0
Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS open
INFO: [/hello.txt] Method succeeded. Result: 0
Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS read
INFO: [/hello.txt] Method succeeded. Result: 13
Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS flush
INFO: [/hello.txt] Method succeeded. Result: 0
Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS lock
INFO: [/hello.txt] Method succeeded. Result: -78
Oct 13, 2013 11:55:49 PM net.fusejna.examples.HelloFS release
INFO: [/hello.txt] Method succeeded. Result: 0

but then cating it a second time again gives:

Oct 13, 2013 11:55:52 PM net.fusejna.examples.HelloFS open
INFO: [/hello.txt] Method succeeded. Result: 0
Oct 13, 2013 11:55:52 PM net.fusejna.examples.HelloFS flush
INFO: [/hello.txt] Method succeeded. Result: 0
Oct 13, 2013 11:55:52 PM net.fusejna.examples.HelloFS lock
INFO: [/hello.txt] Method succeeded. Result: -78
Oct 13, 2013 11:55:52 PM net.fusejna.examples.HelloFS release
INFO: [/hello.txt] Method succeeded. Result: 0

(Notice the lack of a call to HelloFS's read method.)

This is on OS X 10.7 with

java version "1.7.0_10"
Java(TM) SE Runtime Environment (build 1.7.0_10-b18)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

[EtiennePerot]

I can't reproduce this (read always shows up on each cat for me), I'm guessing the caching behaviour is OS-dependent.

As for how to fix it, I'm not sure but my gut tells me that these bits are not what they should be. JNA unfortunately makes it pretty painful (i.e. completely manual) to use structs with bitfields in them.

So if I understand correctly, we should have something like this:

32-bit words: ... /------- Word boundary --------\  /   -   -   -   -  --- Word boundary --------\
Offset:       ... 0123456789ABCDEF0123456789ABCDEF  0   1   2   3   4  56789ABCDEF0123456789ABCDEF
C struct:     ... <--- 32-bits int writepage ----> <A> <B> <C> <D> <E> <---- 27-bits padding ---->
Java struct:  ... \---- public int writepage ----/  \-------- public int flags_bitfield ---------/

Where A is direct_io, B is keep_cache, etc. Thus, BIT_KEEP_CACHE should be the second leftmost bit of a 32-bit integer, which on big-endian would be 1 << 30 or 1 << 6 on little-endian. AFAIK the JVM is big-endian, so try setting BIT_KEEP_CACHE to 1 << 30 in StructFuseFileInfo and see what happens.

My second gut feeling is simply your operating system ignoring what FUSE says, which isn't out of the question either.

[lynaghk]

Sorry for the late reply---I wanted to test out your theory that it might be OS dependent.
On a 64 bit Debian Linux machine the behavior is what you report; reads from FUSE on every invocation.

I'll see if there are some global options with OS X FUSE that I can use to disable buffering and what, if anything, would need to change with the JNA code to support it.

[lynaghk]

(I tried private static final int BIT_KEEP_CACHE = 1 << 30; and 1 << 6 as per your suggestion, but no change in behavior.)