Date: Wed, 31 Jul 1996 11:29:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rnordier@iafrica.com (Robert Nordier) Cc: jkh@time.cdrom.com, pst@shockwave.com, hackers@freebsd.org, current@freebsd.org Subject: Re: anyone working on upgrading the msdosfs to NetBSD levels? Message-ID: <199607311829.LAA02458@phaeton.artisoft.com> In-Reply-To: <199607221808.UAA00225@eac.iafrica.com> from "Robert Nordier" at Jul 22, 96 08:08:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The FAT fs primitives are done and tested and I'm currently working > on VFAT support. Before you get too far on that, I have the algorithm it uses to avoid short name name space collisions. It's not pretty, but it works, and I think that was all Microsoft really cared about. Unfortunately, since the struct nameidata is not yet treated as an opaque object in a lot of places, it's not possible to do the lookup in multiple name spaces correctly in the vfs_lookup.c, where it belongs. I'm also not sure about the long name space storage which is in ISO-10646/16 (16 bit Unicode), since it is not possible to pass Unicode across the lookup interface (this will be a problem for any NTFS as well -- Linux is unfortunately way ahead of BSD here). The long names are case sensitive on storage and case insensitive on lookup. I don't know how you could emulate this for a DOS client (for instance) reading for a BSD mounted FS mapped to a DOS drive letter by the emulator. My opinion is that lookup changes are required, including adding a bit priority vector and name space identifier parameter to the VOP_LOOKUP. I can't help with the Unicode stuff given the current state of the BSD VFS; my suggestion is to punt, and treat the high byte as zero in all cases, converting it to ISO-8859-1 (Latin 1). This will damage utility for anyone outside the Latin 1 scope, but that can't be helped without the underlying VFS changes (appologies to non-Latin 1 using countries up front). If you get to where you need to work on name collision, let me know, and I can describe the algorithm in a couple of pages. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607311829.LAA02458>