From owner-freebsd-fs@FreeBSD.ORG Tue Oct 17 21:09:50 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A08916A40F for ; Tue, 17 Oct 2006 21:09:50 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7559143D76 for ; Tue, 17 Oct 2006 21:09:43 +0000 (GMT) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 21923 invoked from network); 17 Oct 2006 21:09:43 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Oct 2006 21:09:43 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 813BC28433; Tue, 17 Oct 2006 17:09:42 -0400 (EDT) To: freebsd-fs@freebsd.org References: <200609292159.18282.absorbb@gmail.com> <44d58sos3a.fsf@be-well.ilk.org> From: Lowell Gilbert Date: Tue, 17 Oct 2006 17:09:42 -0400 In-Reply-To: (Mark Day's message of "Tue, 17 Oct 2006 11:13:31 -0700") Message-ID: <44d58qmyy1.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ntfs broken when share through samba3 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, 17 Oct 2006 21:09:50 -0000 mday@apple.com (Mark Day) writes: > On Oct 16, 2006, at 2:42 PM, Lowell Gilbert wrote: > >> absorbb@gmail.com (=D0=98=D0=BB=D1=8C=D0=B4=D0=B0=D1=80 =D0=9D=D1=83=D1= =80=D0=B8=D1=81=D0=BB=D0=B0=D0=BC=D0=BE=D0=B2) writes: >> >>> This old already reported bug. >>> But situation have'nt changed. >> >> For example, kern/86965. >> >>> There is very simple patch that fix this bug: >>> >>> --- usr/src/sys/fs/ntfs/ntfs_vnops.c Mon Mar 13 00:50:01 2006 >>> +++ home/voxel/stuff/ntfs_vnops.c Thu Aug 31 09:22:08 2006 >>> @@ -187,7 +187,8 @@ >>> vap->va_fsid =3D dev2udev(ip->i_dev); >>> vap->va_fileid =3D ip->i_number; >>> vap->va_mode =3D ip->i_mp->ntm_mode; >>> - vap->va_nlink =3D ip->i_nlink; >>> + vap->va_nlink =3D (ip->i_nlink ? ip->i_nlink : 1); >>> + //vap->va_nlink =3D ip->i_nlink; >>> vap->va_uid =3D ip->i_mp->ntm_uid; >>> vap->va_gid =3D ip->i_mp->ntm_gid; >>> vap->va_rdev =3D 0; /* XXX UNODEV ? */ >>> >>> but it seems to be not beaty solution >> >> Not beautiful, indeed. >> >> I was playing around with this, and although that change would work >> around the problem in (at least) most cases, I am not sure that it is >> truly correct. >> >> I am not an expert at filesystems, and certainly have little knowledge >> of NTFS. However, my observations confuse me considerably. The main >> issue is that if you read from a file (on NTFS, with a link count of >> zero according to ls(1)), the link count becomes populated. I cannot >> see how that would happen, because the ntnode structure link count is >> not modified except when reading the whole structure from the disk, >> and the on-disk node is not being changed. To confuse things further, >> the link count is changed to 2, not 1, on ordinary files that have >> only a single directory entry. I do not believe that streams are at >> issue, because the file has no open file descriptors remaining >> according to fstat(1). > > IIRC, the NTFS code tries to populate a vnode based on the limited > information present in the directory entries it sees. It's trying to > avoid having to go read the Master File Table record (the i-node > equivalent) until it actually needs that information (such as the link > count). The ntfs_loadntnode() routine will read in the MFT record and > populate the rest of the vnode's fields. There's a flag > (VG_DONTLOADIN) to pass to ntfs_vgetex to control whether the MFT-=20 > based fields get filled in when get the vnode. > > Hope this helps, Yes, that clears things up for me considerably. Thank you, Mark. One thing I can see from that is that the proper loading of the ntnode from the MFT will not be affected by faking a link count; the IN_LOADED flag will take care of that. Furthermore, using that same flag to add to this patch, so that a zero count in the MFT will not be ignored, will avoid the rest of my major concerns. The patch would end up more like: --- usr/src/sys/fs/ntfs/ntfs_vnops.c Mon Mar 13 00:50:01 2006 +++ home/voxel/stuff/ntfs_vnops.c Thu Aug 31 09:22:08 2006 @@ -187,7 +187,8 @@ vap->va_fsid =3D dev2udev(ip->i_dev); vap->va_fileid =3D ip->i_number; vap->va_mode =3D ip->i_mp->ntm_mode; - vap->va_nlink =3D ip->i_nlink; + vap->va_nlink =3D (ip->i_nlink || ip->i_flag & IN_LOADED ? ip->i_nlink := 1); vap->va_uid =3D ip->i_mp->ntm_uid; vap->va_gid =3D ip->i_mp->ntm_gid; vap->va_rdev =3D 0; /* XXX UNODEV ? */ This still doesn't meet POSIX requirements, but to do that would require reading the whole MFT entry every time, instead of just the directory entries. That optimization speeds things up a lot in large filename searches, so this seems like a good compromise to me. Or am I missing something?