Problems accessing files with gvfs-fuse-daemon

Joe Marcus Clarke marcus at marcuscom.com
Sun Feb 7 20:49:35 UTC 2010


On Sun, 2010-02-07 at 21:44 +0100, Gustau Pérez wrote:
> 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.

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

> 
>    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.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/20100207/64600f0d/attachment.pgp


More information about the freebsd-gnome mailing list