Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Feb 2010 21:44:29 +0100
From:      =?ISO-8859-1?Q?Gustau_P=E9rez?= <gperez@entel.upc.edu>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        freebsd-gnome@freebsd.org
Subject:   Re: Problems accessing files with gvfs-fuse-daemon
Message-ID:  <4B6F262D.1020509@entel.upc.edu>
In-Reply-To: <1265574585.24140.6.camel@shumai.marcuscom.com>
References:  <4B6D4624.803@entel.upc.edu> <4B6F1D6B.2070408@entel.upc.edu>	<1265573861.24140.3.camel@shumai.marcuscom.com>	<4B6F21B3.1020303@entel.upc.edu> <1265574585.24140.6.camel@shumai.marcuscom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
En/na Joe Marcus Clarke ha escrit:
> On Sun, 2010-02-07 at 21:25 +0100, Gustau Pérez wrote:
>   
>>>>>   I posted the trace to pastebin :
>>>>>
>>>>>             http://pastebin.com/m79cf37f3
>>>>>
>>>>>   If you search for socket syscalls, you'll see it normally creates two,
>>>>> and then it connects them to a unix socket in /var/tmp. For example I
>>>>> see it connecting two sockets to
>>>>>
>>>>>         /var/tmp/gvfs-gus-B9lo36Ky/socket1
>>>>>         /var/tmp/gvfs-gus-B9lo36Ky/socket2
>>>>>   
>>>>>    But only the second can be found. I can't see the first. So probably
>>>>> this is the problem. Anyone has the same problem ? I can provide more info.
>>>>>       
>>>>>           
>>> As I said, you would be better off contacting the fuse maintainer.
>>>
>>> Joe
>>>
>>>   
>>>       
>>    Hi again,
>>
>>    Well, I think those files had been openened by gvfs-fuse-daemon, I
>> see gvfs-fuse-daemon opening them in the trace file. So I'm not sure
>> whether it is fuse responsability or not.  Am I right ?
>>     
>
> gvfs-fuse-daemon is nothing more than a fuse client.  The daemon
> initializes the fuse subsystem, then it's up to fuse to invoke callbacks
> in gvfs-fuse-daemon.  Look at the code in gvfs' client/gvfsfusedaemon.c
> for more details.
>   

    I've been debugging gvfsfusedaemon.c adding some printf's to the
vfs_read callback function, cause first
I though it was a locking problem. gvfsfusedaemon uses a lock to protect
the access when reading a given file. With these printf's I saw that was
not the problem.

   So it could be a problem somewhere else in gvfsfusedaemon or maybe in
fuse (I suppose in fusefs-libs not fusefs-kmod). I think the hint is
those pair of sockets it creates. I see it creates some sockets to dbus
in gvfsdaemondbus.c,  may be this is the source of the problem.

   What I don't understand is why  fusefs-ssh is working fine,
transfering media for a long time without problems. Something doesn't
work somewhere, but i don't know what.

   Thanks again,

   Gus

  
>   
>>    If you still think it is fuse responsability I'll contact the fuse
>> mantainer, but it is kinda strange fusefs-ssh has not that problem in my
>> config.
>>
>>    Do you guys have the same problem accessing $HOME/.gvfs files ?
>>     
>
> I don't use fuse.
>
> Joe
>
>   


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B6F262D.1020509>