From owner-freebsd-gnome@FreeBSD.ORG Sat Feb 13 17:26:43 2010 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB341106566C for ; Sat, 13 Feb 2010 17:26:43 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 313E58FC08 for ; Sat, 13 Feb 2010 17:26:42 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id o1DHQeHu000664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2010 18:26:40 +0100 Received: from [192.168.100.200] (9.Red-88-11-97.dynamicIP.rima-tde.net [88.11.97.9]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o1DHQZEN032314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 18:26:39 +0100 Message-ID: <4B76E0CB.6040806@entel.upc.edu> Date: Sat, 13 Feb 2010 18:26:35 +0100 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.23 (X11/20100207) MIME-Version: 1.0 To: freebsd-gnome@freebsd.org 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> In-Reply-To: <1265575770.1685.0.camel@shumai.marcuscom.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sat, 13 Feb 2010 18:26:40 +0100 (CET) Cc: =?ISO-8859-1?Q?Gustau_P=E9?= Subject: Re: Problems accessing files with gvfs-fuse-daemon X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 17:26:43 -0000 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