From owner-freebsd-fs@FreeBSD.ORG Tue Oct 17 18:13:41 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 4ACFE16A403 for ; Tue, 17 Oct 2006 18:13:41 +0000 (UTC) (envelope-from mday@apple.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54A2F43D5A for ; Tue, 17 Oct 2006 18:13:32 +0000 (GMT) (envelope-from mday@apple.com) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k9HIDWA2021194 for ; Tue, 17 Oct 2006 11:13:32 -0700 (PDT) Received: from [17.202.43.217] (unknown [17.202.43.217]) by relay8.apple.com (Apple SCV relay) with ESMTP id EAB69638 for ; Tue, 17 Oct 2006 11:13:31 -0700 (PDT) Message-Id: From: Mark Day To: freebsd-fs@freebsd.org In-Reply-To: <44d58sos3a.fsf@be-well.ilk.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-Smtp-Server: relay.apple.com Mime-Version: 1.0 (Apple Message framework v851) Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Oct 2006 11:13:31 -0700 References: <200609292159.18282.absorbb@gmail.com> <44d58sos3a.fsf@be-well.ilk.org> X-Mailer: Apple Mail (2.851) X-Brightmail-Tracker: AAAAAA== 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 18:13:41 -0000 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 =20 information present in the directory entries it sees. It's trying to =20= avoid having to go read the Master File Table record (the i-node =20 equivalent) until it actually needs that information (such as the link =20= count). The ntfs_loadntnode() routine will read in the MFT record and =20= populate the rest of the vnode's fields. There's a flag =20 (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, -Mark