Date: Wed, 3 Feb 93 17:23:05 -0800
From: pdh AT netcom DOT com (Phil Howard )
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: mapping long names to 8.3 names

Some food for thought:

If one is careful enough in the design of programs that map long names to
8.3 names, you could also add other unix file system features to MSDOS in
the process.  This can include hard links and symbolic links.

Because hard links in UNIX can span different subdirectories, the scheme
would have to NOT depend on the tree structure of the long names being
exactly reproduced with merely short names.  For example, suppose the files
"aaa/xyz" and "xxx/abc" are hardlinked as the same file in the original
unix file tree.  You would want to have just one instance of the data,
but where would it actually be placed (regardless of its name)?  Also there
is the little matter of a link count.

The solution, if you want to go with a full unix file mapping, is to keep
all the "unix like" files in a flat set of file.  This flat set can be
arbitrarily broken into a number of MSDOS subdirectories for performance
purposes, but that structuring would not relate in any way to the unix
structuring.

A "unix directory" would be a file that contained a list of the long names
in that directory, and the MSDOS names they point to.  The analogy in unix
is that the MSDOS file names would be like inode numbers.  My original
scheme was to just use numbers anyway.  But semi-mangled names that look
somewhat recognizable could have its uses, especially in maintenance and
error recovery.  The "unix directory" file would itself be one of these
mangle-named files, pointed to by some other directory (or the root unix
directory).

I had a couple of solutions for the inode link count.  One was to store an
actual inode file.  That scheme variation would have directory files really
containing inode numbers, and a second layer of mapping in the inode file to
reference actual MSDOS files.  Another scheme was to store the link count
as the extension of the MSDOS file name; this would require renaming the
MSDOS file each time the link count changed, but it would make it easy to
see what the link count was from MSDOS tools.  This would apply to files
and directories.

For symbolic links, I had considered using a variation name as the flag to
indicate that it was a symbolic link.  Likewise, another variation was to
indicate directories.  The original scheme I had in mind was to have 8.3
names like:
    regular files       Fiiiiiii.nnn
    directories         Diiiiiii.nnn
    symbolic links      Liiiiiii.nnn

Again, I had considered only using numbers for the "iiiiiii" part, but
using some sort of recognizable characters should work just fine as long
as the logic to assign the mapping makes sure of uniqueness over the
whole flat set.  If a split MSDOS directory approach is also used, the
split directory names could help in uniqueness, but added care has to be
taken.  Another approach I though of was:
    regular files       kk\Fiiii.nnn
    directories         kk\Diiii.nnn
    symbolic links      kk\Liiii.nnn
where "kk\" was a directory named by the inode number, modulo 100 or some
other chosen value (100 is probably not really a very good choice) and the
"iiii" part is what is left.

I am sure there could be many schemes, including many with non-numeric MSDOS
names.  But whatever is done, I would sure like to see it come with the
ability to support hard links and symbolic links.  Also, the interface used
to access these long names should allow accessing the ordinary MSDOS names
in some way, such as "mounting" the various MSDOS disks as "/a:/" and "/b:/"
and "/c:/" and "/d:/", etc.  Then tools written for doing things with the
unix files could be used with MSDOS files (with their limitations).  Perhaps
this should be done in a way similar to how MSDOS file systems are usually
mounted onto LINUX so that tools can be used in the same way (I don't know
offhand what that is since I have not installed a LINUX system yet).