Date: Tue, 10 Feb 1998 10:42:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Cc: tlambert@primenet.com, jkh@time.cdrom.com, jbryant@unix.tfs.net, freebsd-current@FreeBSD.ORG Subject: Re: merging win95 and nt filesystem changes into msdosfs Message-ID: <199802101042.DAA25601@usr05.primenet.com> In-Reply-To: <199802101022.NAA03023@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Feb 10, 98 01:21:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Please apply my nami/nameifree patches before attempting this. > > Where can I gen them? >From the -current list archives, or in ~terry on freefall.freebsd.org. > > If you > > do not, the resulting created long file names will not be usable from > > Windows95. Specifically, 4DOS get a short name list, and then goes back > > and requests the long names given the short names. > > Well, I don't use 4DOS, and believed that created long file names are ok. > Scandisk doesn't report any problems also. How 4DOS can have problems? > Doesn't it use standard DOS or Windows syscalls? It uses DOs calls to get the directory, then goes back and uses Win95 calls to get the long name from the short name. The problem is that the same algorithm *must* be used for this to work reliably. This is documented in the IFS.DOC in the DDK of the MSDN Level II developer CDROM, along with the collision algortihm. I published the algorithm (from observation of behaviour, later verified by the MS document) both on the SAMBA mailing list, and in the -current and -hacker's archives (in reply to Rober Nordier, who was precviously working on VFAT support in FreeBSD -- you may wish to contact him). > > [problems with locales] > > This is indeed a big headache for me. I have several files with Russian > filenames, and msdosfs doesn't do something minimally correct with them > at all. So I am interested to look at your code. But I believe that in the > meantime something working in real life is already useful. If the path buffer is opaque, you can send both Unicode and 8.3 data down, based on what the FS that's decoding the component wants. There is a UNICODE flag in namei.h for this. The problem is that you can't guarantee not to sleep when traversing the directory looking for the numeric tail for the short name. This means that it's not safe to reeenter the VOP_LOOKUP with the CREATE/RENAME flags set on a given dir. The only way you can guarantee this in the face of the parent -> child traversal race condition is to do the name binding in the CREATE/RENAME commit while holding a lock on the directory. You also need to flag if the name going down is a valid 8.3 name, or if it is a long name. This is only for the terminal path component (Win95 must do it for each path component, so this is one difference). The reason for this problem is that in VFAT a directory entry *is* an inode. I did effectively this when I converted FFS/UFS for Windows 95 IFS, and added a Unicode name space and 8.3 names for FFS/UFS directory entries; the problems I faced are exactly the inverse of the problems you face. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802101042.DAA25601>