Date: Tue, 17 Oct 2006 11:13:31 -0700 From: Mark Day <mday@apple.com> To: freebsd-fs@freebsd.org Subject: Re: ntfs broken when share through samba3 Message-ID: <AEDCDDFB-CAD9-4F33-92FE-FA3D3E30F485@apple.com> In-Reply-To: <44d58sos3a.fsf@be-well.ilk.org> References: <200609292159.18282.absorbb@gmail.com> <44d58sos3a.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEDCDDFB-CAD9-4F33-92FE-FA3D3E30F485>