From owner-freebsd-hackers  Sun Apr 27 12:54:39 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA25815
          for hackers-outgoing; Sun, 27 Apr 1997 12:54:39 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA25810
          for <hackers@FreeBSD.org>; Sun, 27 Apr 1997 12:54:36 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09095; Sun, 27 Apr 1997 12:49:03 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199704271949.MAA09095@phaeton.artisoft.com>
Subject: Re: VFAT 32 support in msdosfs
To: joerg_wunsch@uriah.heep.sax.de
Date: Sun, 27 Apr 1997 12:49:03 -0700 (MST)
Cc: hackers@FreeBSD.org
In-Reply-To: <19970427093916.AH02880@uriah.heep.sax.de> from "J Wunsch" at Apr 27, 97 09:39:16 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > >[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.