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