From owner-freebsd-fs@FreeBSD.ORG Tue Aug 3 21:00:33 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C95E1065675 for ; Tue, 3 Aug 2010 21:00:33 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 201D78FC1F for ; Tue, 3 Aug 2010 21:00:32 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:37624 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OgOOh-0007aH-GH; Tue, 03 Aug 2010 22:47:39 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <4C582968.9000303@fsn.hu> Date: Tue, 3 Aug 2010 22:47:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1147918452.245970.1280844811813.JavaMail.root@erie.cs.uoguelph.ca> <4C582968.9000303@fsn.hu> To: Attila Nagy X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: NFS problem: file doesn't appear in file listing, but can be accessed directly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:00:33 -0000 On 03.08.2010, at 16:36, Attila Nagy wrote: >> You can try replacing the client and server with the experimental >> ones and see if that fixes the problem. >> For the client: mount with "-t newnfs" instead of "-t nfs" >> For the server: start both mountd and nfsd with the "-e" option > Sure. It works with the newnfs client, so it must be either a weird = interaction between the FreeBSD server and client (old), or a client = bug. Have you tried comparing on-the-wire NFS requests and responses between = newnfs and legacy nfs clients for your test case? Maybe you can rule out = the former like this. Or at least prove that the server actually = responds correctly to the READDIR request. Markus