Date: Sun, 27 Apr 1997 12:49:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.org Subject: Re: VFAT 32 support in msdosfs Message-ID: <199704271949.MAA09095@phaeton.artisoft.com> In-Reply-To: <19970427093916.AH02880@uriah.heep.sax.de> from "J Wunsch" at Apr 27, 97 09:39:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >[OEMSR2] machines are capable of reading long-name-in-volume-label FAT
> > >drives ("VFAT").
>
> > This is nonsense.
> >
> > FAT32 is a superset of FAT16/FAT12. The OEMSR2 version of io.sys
> > supports all three.
>
> Hey, this is not win95-hackers@micro$oft.com.
>
> Feel free to discuss your first unicode filesystem for FreeBSD here.
Technically, to be interoperable with the late-binding mechanism used
by Windows 95, FreeBSD should internally use Unicode when talking to
te VFAT FS.
Also, if you want to be technical, in order to support the short name
generation and collision algorithm propery, without possibility of
deadlock, then FreeBSD needs to be able to communicate multiple
terminal path components into the create/rename/mkdir VOPs, so it
needs to treat the contents of the struct componentname in the struct
nameidata as interface-opaque data.
This means that the terminal component name, and in fact whether the
cn_pnbuf contains Unicode/non-Unicode data based on an FS flag, needs
to be isolated in the code.
It's a short step from supporting two name spaces to supporting N name
spaces...
Regards,
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?199704271949.MAA09095>