Date: Sun, 07 Feb 2010 15:49:30 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Gustau =?ISO-8859-1?Q?P=E9rez?= <gperez@entel.upc.edu> Cc: freebsd-gnome@freebsd.org Subject: Re: Problems accessing files with gvfs-fuse-daemon Message-ID: <1265575770.1685.0.camel@shumai.marcuscom.com> In-Reply-To: <4B6F262D.1020509@entel.upc.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-Y/V306C02hF80XQaPJIy Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Sun, 2010-02-07 at 21:44 +0100, Gustau P=E9rez wrote: > En/na Joe Marcus Clarke ha escrit: > > On Sun, 2010-02-07 at 21:25 +0100, Gustau P=E9rez wrote: > > =20 > >>>>> 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 > >>>>> =20 > >>>>> But only the second can be found. I can't see the first. So prob= ably > >>>>> this is the problem. Anyone has the same problem ? I can provide mo= re info. > >>>>> =20 > >>>>> =20 > >>> As I said, you would be better off contacting the fuse maintainer. > >>> > >>> Joe > >>> > >>> =20 > >>> =20 > >> 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 ? > >> =20 > > > > gvfs-fuse-daemon is nothing more than a fuse client. The daemon > > initializes the fuse subsystem, then it's up to fuse to invoke callback= s > > in gvfs-fuse-daemon. Look at the code in gvfs' client/gvfsfusedaemon.c > > for more details. > > =20 >=20 > 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. >=20 > 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 >=20 > 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. >=20 > Thanks again, >=20 > Gus >=20 > =20 > > =20 > >> 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 ? > >> =20 > > > > I don't use fuse. > > > > Joe > > > > =20 >=20 >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-Y/V306C02hF80XQaPJIy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAktvJ1gACgkQb2iPiv4Uz4c2XwCeL6ix0fxt0LNfIDFrdKPBaAMs cccAnjy5Cni33wHZzY8ueALxBylSoUFR =Qw6z -----END PGP SIGNATURE----- --=-Y/V306C02hF80XQaPJIy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1265575770.1685.0.camel>