Date: Sun, 07 Feb 2010 22:26:25 +0100 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= <gperez@entel.upc.edu> To: Joe Marcus Clarke <marcus@marcuscom.com>, freebsd-gnome@freebsd.org, gperez@entel.upc.edu Subject: Re: Problems accessing files with gvfs-fuse-daemon Message-ID: <4B6F3001.8000808@entel.upc.edu> In-Reply-To: <1265575770.1685.0.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> <4B6F262D.1020509@entel.upc.edu> <1265575770.1685.0.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: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 > Well, in fusefs-libs I see I changes the file operations if the direct_io option is passed. But for me fusefs is a new world, and I don't know how the pieces fit in fusefs. So I think I would be easier to first check gvfsdaemondbus and gvfsfusedaemon. Direct_io seems to have some impact, but the problem remains there when using a no-simple applications (for example vlc and totem make the problem arise). The pair of sockets problem makes me think direct_io solves something, but there is another problem. And I remember pcbsd opening samba shares and vlc and gimp opening files in those shares through dolphin. I don't know if kde4 and its kios use fuse or not. I'll check it. I'll contact the fusefs mantainer, maybe he has any idea, but if anyone has some spare time and want to have fun ... Regards, Gus -- 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?4B6F3001.8000808>