Date: Tue, 10 Feb 1998 09:13:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Cc: jkh@time.cdrom.com, jbryant@unix.tfs.net, freebsd-current@FreeBSD.ORG Subject: Re: merging win95 and nt filesystem changes into msdosfs Message-ID: <199802100913.CAA23783@usr05.primenet.com> In-Reply-To: <199802100719.KAA01219@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Feb 10, 98 10:19:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802100913.CAA23783>