Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!mcnc!duke!bet
From: bet@orion.mc.duke.edu (Bennett Todd)
Newsgroups: comp.unix.wizards
Subject: Re: Filename length statistics
Message-ID: <14753@duke.cs.duke.edu>
Date: 14 Jun 89 21:38:57 GMT
References: <19976@adm.BRL.MIL> <4530@ficc.uu.net> <14749@duke.cs.duke.edu>
Sender: news@duke.cs.duke.edu
Reply-To: bet@orion.mc.duke.edu (Bennett Todd)
Organization: Diagnostic Physics, Raddiology, DUMC
Lines: 16
In-reply-to: bet@orion.mc.duke.edu (Bennett Todd)

I said I would post statistics over all our home directories, and over
the whole system, when the runs finished. Well, they finished much
quicker than I had feared, and I looked them over. Basically, they
agreed much more closely with Peter da Silva's figures than with those
over my home directory. I guess I'm an anomaly:-). I still think
fixed-length filenames belong in the same category as fixed-length line
buffers in editors and suchlike; a reasonable design compromise for a
first revision, to prove the concept and keep the prototype
implementation simple, but not a desirable limitation in a final
production version. And, like with line length limits in editors, I
believe that a GOOD implementation won't inflict either undue code bulk
or undue speed degradation, as the price of going to a dynamically
allocated varying length implementation.

-Bennett
bet@orion.mc.duke.edu