Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!ogicse!unmvax!ariel.unm.edu!hydra.unm.edu!dmckeon
From: dmckeon@hydra.unm.edu (Denis McKeon)
Newsgroups: comp.unix.sysv386
Subject: Re: 14 character limitation in filenames
Message-ID: <1991Feb16.163535.13418@ariel.unm.edu>
Date: 16 Feb 91 16:35:28 GMT
References: <1991Feb11.072316.193@ico.isc.com> <27B7F558.32E7@tct.uucp> <1991Feb13.225958.10248@robobar.co.uk>
Organization: Connemara - Computing for People
Lines: 45
X-Mailer: Mail User's Shell (7.0.3 12/22/89)
Status: OR

Since AT&T's 14 isn't enough, and BSD's to null or 255 is slower to
read (or is it?), how about encoding the current max filename length
following the . or .. entries (conventionally the first two dir entries).

Conceptually: ( '_' == visible pad char)

ruler 789 123456789 123456789 123456789 123456789

.22___________________
..____________________
file.c
file-with-lengthy-name
file.o
etc.

or

.46___________________________________________
..____________________________________________
file.c
file-with-humongous-name-and-many-extensions__
file.o
etc.

You might take a performance hit to read '.' and the length, then read
the rest of the dir in length-size chunks - but you could do it more
like BSD (which I assume reads a dir block by block & looks for nulls)
- read a block, pull out the length, & walk down the dir in <length> chunks.
(The examples assume that length is (n*16)-2.)  

You take a whopping performance hit when you create a filename just
longer than the current max - while the OS goes off & makes a directory
with bigger name slots, copies the old names & other info, deletes old
dir, etc.  - but you get names of any (reasonable) length you want.
Reducing (unneeded) directory size is another problem.
Enforcing the . and .. first convention is a bit ungeneral.

This suggestion seems too simple to be workable - maybe I should go back 
and read Dietel some more - surely I'm overlooking some obvious problems - 
what's inherently bad about a file-system with heterogenous file name length?
How is this a worse solution than Berkeley's?  

--
Denis
dmckeon@hydra.unm.edu