14 character limitation in filenames

[Denis McKeon]

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 at hydra.unm.edu