From owner-freebsd-current Tue Feb 10 02:42:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA29500 for current-outgoing; Tue, 10 Feb 1998 02:42:56 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA29495 for ; Tue, 10 Feb 1998 02:42:54 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id DAA04214; Tue, 10 Feb 1998 03:42:53 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd004209; Tue Feb 10 03:42:44 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA25601; Tue, 10 Feb 1998 03:42:40 -0700 (MST) From: Terry Lambert Message-Id: <199802101042.DAA25601@usr05.primenet.com> Subject: Re: merging win95 and nt filesystem changes into msdosfs To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Date: Tue, 10 Feb 1998 10:42:40 +0000 (GMT) Cc: tlambert@primenet.com, jkh@time.cdrom.com, jbryant@unix.tfs.net, freebsd-current@FreeBSD.ORG In-Reply-To: <199802101022.NAA03023@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Feb 10, 98 01:21:59 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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