Problems accessing files with gvfs-fuse-daemon

Gustau Pérez gperez at entel.upc.edu
Sat Feb 13 17:26:43 UTC 2010


 
   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 ?

   Regards,

   Gus

 


-- 
PGP KEY : http://www-entel.upc.edu/gus/gus.asc



More information about the freebsd-gnome mailing list