From: Hans Beckérus <hans.beckerus@gm...> - 2011-05-26 11:04:12
I experience a very strange behavour in one of my FUSE based applications
when accessing files
over a shared Samba network Linux -> Windows7. It is the access from Windows
that are causing my headache.
The fuse_file_info handle (pointer) is what I can tell _always_ the same in
every open() call made
and the 'fh' member seems to be reset to 0 for each new call to open().
In the later read() calls the 'fh' member should be set to what is saved to
it (optional) in the open() call.
I have verified that the 'fh' member is written back to fuse_file_info and
it is unique in every case.
But, then the problem starts :( The read() calls are not working as expected
when a file is opened multiple times
and for which the initial/first open() keeps the file open during the whole
time and reads from it constantly.
I get all the expected read() calls (with expected offsets) but for some of
them the 'fh' member is not unique and
is shared with the one allocated to the _first_ open request!? The incorrect
read() does not belong there.
I know that by checking the offset.
I use the 'fh' member to link to important context information and
bookkeeping data about each session.
The filesystem can not jump back and forth easily in the stream so if the
context is wrong the application will fail.
The problem seems to be related to what I get from fuse_get_context()->pid.
In the case it fails, the active open file, and one of the new open() and
read() counter part calls all report the
same pid!? Should that really be the case? It is two separate open calls,
should then not the
pid be unique too? When the pid is different from the initial open it seems
Another strange things is that it is not 100% repoducible! But almost.
If I just access the same file simultaneously from my FUSE mount point on
Linux it works every single time,
that is, the fuse_get_context()->pid is always unique for each open() call
and so is the 'fh' member provided
in the read() calls.
Could there be some issue with having the FUSE mount point exported over the
network using Samba
I am using FUSE 2.7.4.
Any ideas what could be the cause of this?
From: Hans Beckérus <hans.beckerus@gm...> - 2011-05-27 07:49:38
The problem is solved.
The solution was to make sure the fi->keep_cache flag is set to avoid
flushing of the cache at subsequent open() calls on the same file.
I discovered this by testing the kernel_cache mount option. But that was
a little bit too much brute force. Using the keep_cache flag, the
behavior can be controlled on a per file basis.