From owner-freebsd-current Tue Feb 10 01:13:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA15082 for current-outgoing; Tue, 10 Feb 1998 01:13:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15073 for ; Tue, 10 Feb 1998 01:13:13 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id CAA29896; Tue, 10 Feb 1998 02:13:12 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd029882; Tue Feb 10 02:13:10 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id CAA23783; Tue, 10 Feb 1998 02:13:07 -0700 (MST) From: Terry Lambert Message-Id: <199802100913.CAA23783@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 09:13:07 +0000 (GMT) Cc: jkh@time.cdrom.com, jbryant@unix.tfs.net, freebsd-current@FreeBSD.ORG In-Reply-To: <199802100719.KAA01219@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Feb 10, 98 10:19:44 am 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 > > There's no one who currently "owns" MSDOSFS, that's why, and no one to > > do the work of integrating changes from NetBSD or any other OS. Any > > volunteers? > > Me. Please apply my nami/nameifree patches before attempting this. 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. The previously discussed short name generation algorithm will fail to result in names that will work with this commonly used shareware shell. The MKS tools cwBourne shell does the same thing. Also, note that because the implementation of the pathname buffer representation is known to the FS's (the FS's must free the buffer on behalf of the caller in the current implementation), you will not be able to round-trip the Unicode via the pathname buffer. As a result, you will have to choose a specific locale to use to create the file names. The simplest of these will be the ISO 8859-1 locale, since it maps into code page 0 of the Unicode standard. Unfortunately, this will mean that VFAT names created in a different locale will be impossible to round-trip out to the user's current locale. You will also be unable to localize this support to a non-ISO 8859-1 using country. This is basically a result of your having to do the path data converision to Unicode under the covers of namei instead of over them, where you would have (putative) access to the user's environment. This in turn is a result of the non-inheritance of path component attributes across component lookups in the underlying FS. It's nice to see people becoming interested in FS hacking, but care should be taken: the framework in which you will be hacking is not as orthogonal as it first appears. 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