14 character limitation in filenames

[Thomas Hoberg]

In article <1991Feb7.041610.5167 at NCoast.ORG>, allbery at NCoast.ORG
(Brandon S. Allbery KB8JRR) writes:
|> As quoted from <.H599ZF at xds13.ferranti.com> by
peter at ficc.ferranti.com (Peter da Silva):
|> +---------------
|> | In article <1991Feb1.003532.15719 at NCoast.ORG> allbery at ncoast.ORG
(Brandon S. Allbery KB8JRR) writes:
|> | > "Silliness"?  I still fail to understand why everyone wants to be
able to
|> | > create files with humongous names --- I don't enjoy typing 14
character file
|> | 
|> | I find 14 a little limiting on occasion, but I've never run out of space
|> | in the 30-character file names on AmigaOS. Since just doubling the size
|> | of a directory entry would give you 30 character filenames, why
bother with
|> | complicated stuff like the BSD system?
|> +---------------
|> 
|> We see eye to eye on this.  255 character file names are ridiculous; if my
|> file name gets *that* long, as far as I'm concerned the file name is
a file in
|> itself.
Well since the older Unix file systems allocate the full 14 bytes for every
directory entry, even if the name is only '.' it made sense to limit them to
some arbitrary but short length. Since Unix was invented in those 75cps tele-
type days terseness was a high priority and 14 characters was more than many
other OSs had to offer. On the other hand, when BSD came around, CRTs were
plentyful and file systems got bigger and bigger, longer and somewhat more
descriptive names seemed desireable. Since the smallest addressable unit of
storage on most computer architectures is the byte and since space for
directory entries in a BSD file system is allocated dynamically (that is, they
use only use as much space as is needed to hold the name), it made no sense to
impose any arbitrary limit beyond that implied by the addressable unit
containing the length of the name.
  The 255 character limit doesn't mean you *have* to use longer names, it just
means that you *can* have names longer than 14 characters. I think, things like
the resource fork in the Apple file system, or user defineable attributes like
those in the OS/2 HPFS can be and are put to good use. If there were some way
to integrate them into Unix, I'd like to have them there, too.
  Somebody in this newsgroup complained about people using variable identifiers
as comments. You complain about the file name being the file or the name being
the message (really popular in advertisement). I agree that names like
XtMakeGeometryRequest() are tedious to type even for a touch typist (such as
me). On the other hand with software monsters like X, there are literally
thousands of function/variable names to remember. Constructing them using
rules and by using full names rather than abbreviations makes it a lot easier
to remember and find them. If you started to abbreviate, you'd get some twenty 
ways do to so. Finding the correct abbreviation would be even more of a
nightmare. Now you could argue, that a software system were you have to
remember thousands of thirty letter names in order to do anything useful
severely hampers a programmer's efficiency, and I'd agree. However in a
non-object oriented system like X we are stuck with just that. In the case of
the Xlib sources, we are faced with file names that had to be abbreviated in
order to fit on a System V file system and since I am currently dealing with
those on a daily basis, I tend to make a case for the ability to use longer
file names. Although I might conjure a flame war up with people concerned about
'machine' efficiency, I'd really like to see a relational database as the
standard 'file system' before I get pensioned (or put in a closed institution).
'human' efficiency tends to be a larger priority for me.
|> 
|> ++Brandon
|> -- 
|> Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
|> Internet: allbery at NCoast.ORG		    Packet: KB8JRR @ WA8BXN
|> America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
|> uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

:-> tom

----
Thomas M. Hoberg   | UUCP: tmh at bigfoot.first.gmd.de  or  tmh%gmdtub at tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET at DB0TUI11 or
+49-30-254 99 160  |         tmh at tub.BITNET