Problems accessing files with gvfs-fuse-daemon

[Joe Marcus Clarke]

On Sat, 2010-02-13 at 18:26 +0100, Gustau Pérez wrote:
> Hello again,
> > Look at what direct_io does, and start there.  What is different when
> > that option is specified?  That option is never passed to the gvfs code,
> > so where in the fuse code does it make an impact?
> >
> > Joe
> >   
>     tried to contact fusefs-{libs|kmod} but I still got no answer. In
> the meantime, I tried to follow the execution of a request, and
> found where it gets stuck.
> 
>    I tried to discover what direct_io does. But fusefs-{libs|kmod} is a
> new world for me, so I decided to investigate gvfs first.
> 
>    It seems that everything fails in function  "static gint
> gettatr_for_file", in the $WRKDIR/client/gvfsfusedaemon.c when calling
> g_file_query_info (which is part of the glib20). To be exact, it asks
> for a number of attributes, one of them is
> "G_FILE_ATTRIBUTE_STANDARD_SIZE".
> 
>    If I remove this attribute from the g_file_query_info call,
> gvfsfusedaemon doesn't get stuck anymore. The problem is that no app
> will be able to use file mounted with gvfs, as all the apps want to know
> the size of the files they are working with.
> 
>    So it seems gvfsfusedaemon does not get stuck, but it's me who does
> not know how to solve the problem, because I don't know
> how "g_file_query_info" gets info about a file in $HOME/.gvfs/...  I
> think that when  g_file_query_info is called (in glib) it
> should in turn try to stat the file, and should be done through fuse,
> which in turn will call again gvfsfusedaemon for the info.
> 
>    I don't know whether I'm right or not. And in if  I'm right, I don't
> how to move forward. Does anyone have an idea how to continue ?

This sounds right.  Chances are things are locking up somewhere in the
kernel.  You should first try breaking into the hung application (and
gvfs-fuse-daemon) with gdb, and get an idea of where in the code path
it's hanging.  I'm betting you will then need to break into the kernel
debugger, and see where in the kernel things get stuck.

Joe

> 
>    Regards,
> 
>    Gus
> 
>  
> 
> 

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20100213/a16222fe/attachment.pgp