Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Jun 1996 13:59:35 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        rnordier@iafrica.com (Robert Nordier)
Cc:        fhackers@jraynard.demon.co.uk, bde@zeta.org.au, hackers@FreeBSD.ORG, phk@FreeBSD.ORG
Subject:   Re: bit 7 in filenames
Message-ID:  <199606092059.NAA02136@phaeton.artisoft.com>
In-Reply-To: <199606091949.VAA00271@eac.iafrica.com> from "Robert Nordier" at Jun 9, 96 09:49:48 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> The vfatfs (== rewritten msdosfs) will not actually create files
> containing illegal DOS filename characters.
> 
> Currently, however, it offers a `translate' option which does a
> semi-intelligent mapping between characters valid on BSD and DOS.
> 
> (Invalid DOS filename characters are those below 0x20, as well as
> the following sixteen:
> 
>      " * + , . / : ; < = > ? [ \ ] |
> 
> All other characters including 0x20 and characters >= 0x80 are
> legal.)
> 
> With the translate option enabled, Bruce's example would be
> acceptable, would be mapped to (say)
> 
>      /msdosfs/a2345678 this is a very long not to mention invalid
>      msdos path.name
> 
> (which DOS itself would accept) and would result in the file
> 
>      A2345678.NAM
> 
> on a FAT filesystem.

Actually, the IFS documentation with the SDK states that a directory
name can contain:

o   $ \ % ' - _ @ ~ ` ! ( )
^ ^
| `- blank space
`- degree symbol

A file name may contain:

o $ \ % ' - _ @ ~ ` ! ( )

The following special characters can also be used in long file names
(but not short ones):

: + , ; = [ ]

Blank spaces can be anywhere in the long name, but blank spaces and
periods at the end of a long name are ignored.

Case is preserved on storage, but ignored on lookup (DOS has seperate
interfaces for directory lookup as opposed to file opening).


I can also give you the "short name generation rules" (which aren't
really documented anywhere).  They require directory iteration and
use of a monotonically increasing numeric "tail" substitution into
the file name (not affecting the extension, if any).


I have somewhat of an advantage, having been involved in a project
that ported the Heidemann framework and some of the FS modules and
most of the BSD FS kernel environment to Windows 95.  8-).

The conversion to parsed-path stuctures greatly aids in use of
Unicode and DOS code-page interoperability... you will need to
incorporate a number of patches if you expect to be able to
support two name binding, lookup, or Unicode storage (We have a
UFS where we have made these modifications).


					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?199606092059.NAA02136>