Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!fauern!opal!tub!gmdtub!bigfoot!tmh From: tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) Newsgroups: comp.unix.sysv386 Subject: Re: 14 character limitation in filenames Message-ID: <319@bigfoot.first.gmd.de> Date: 21 Feb 91 10:04:52 GMT References: <20711@hydra.gatech.EDU> <1991Feb1.003532.15719@NCoast.ORG> <.H599ZF@xds13.ferranti.com> <1991Feb7.041610.5167@NCoast.ORG> Sender: news@bigfoot.first.gmd.de Reply-To: tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) Organization: Gesellschaft fuer Mathematik und Datenverarbeitung (GMD) Lines: 78 In article <1991Feb7.041610.5167@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: |> As quoted from <.H599ZF@xds13.ferranti.com> by peter@ficc.ferranti.com (Peter da Silva): |> +--------------- |> | In article <1991Feb1.003532.15719@NCoast.ORG> allbery@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@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@bigfoot.first.gmd.de or tmh%gmdtub@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@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET