arm@sps.com (Annette Myjak) (01/30/91)
can anyone explain why there's the 14 character limitation in filenames (11 + 3 for extension) in interactive unix? is this common for all 386 based unices? is this limitation likely to be overcome anytime soon? enquiring minds want to know! (this limitation is making it difficult to port a fairly extensive software system.) thanks! annette myjak arm@sps.com
ken@dali.gatech.edu (Ken Seefried iii) (01/30/91)
In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >can anyone explain why there's the 14 character limitation in filenames >(11 + 3 for extension) in interactive unix? Cause AT&T is brain dead? Most all Version 7, System III and System V based Unixes have a 14 character filename limit (11+3? Where'd you get that?). Posix has also followed this silliness... >is this common for all 386 based unices? Yes, save Mach/386 (and OSF/1) and BSD 4.x/386. >is this limitation likely to be overcome anytime soon? Overcome in System V release 4. It *can* be done in System V.3.2 (Tektronix UTek V for the 88000 has flex-names and is 3.2 based). Noone has done it for the 386 that I know of. >enquiring minds want to know! (this limitation is making it difficult >to port a fairly extensive software system.) Yea...join the club... -- ken seefried iii "A sneer, a snarl, a whip that ken@dali.cc.gatech.edu stings...these are a few of my favorite things..."
goer@quads.uchicago.edu (Richard L. Goerwitz) (01/30/91)
In <20711@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: > >>...this [14-char filename] limitation is making it difficult >>to port a fairly extensive software system. > >Yea...join the club... > It may not help in this instance, but check comp.sources.misc for a utility that will take tar'd source trees created on systems not subject to the 14- char limit, rename all overlong files, rename _all references to the over- long files in the archive itself_, recalculate the checksums, and write a new tar file. -Richard (goer@sophist.uchicago.edu)
fangchin@elaine0.stanford.edu (Chin Fang) (01/30/91)
In article <20711@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >>can anyone explain why there's the 14 character limitation in filenames >>(11 + 3 for extension) in interactive unix? > >[..stuff deleted] >>is this common for all 386 based unices? > >Yes, save Mach/386 (and OSF/1) and BSD 4.x/386. And to limited extend, save ESIX V R3.2 rev.D. (you can't use 256 char for /) >>is this limitation likely to be overcome anytime soon? > >Overcome in System V release 4. It *can* be done in System V.3.2 >(Tektronix UTek V for the 88000 has flex-names and is 3.2 based). >Noone has done it for the 386 that I know of. And see above comment. For demonstration, ftp to ypig.stanford.edu annon. and then type ident as passwd to see how 256 char is done in ESIX V R3.2 rev.D >Yea...join the club... Humm... I am afraid it is not necessary yet! Chin Fang Mechanical Engineering Department Stanford University fangchin@portia.stanford.edu ps. It was a struggle to get 256 char file names however, to be fair. since ESIX Tech people in the know won't tell you how. You can try it at your own risk! bottomline: go with R4.x.
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (01/30/91)
In article <20711@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >>can anyone explain why there's the 14 character limitation in filenames >>(11 + 3 for extension) in interactive unix? > >Overcome in System V release 4. It *can* be done in System V.3.2 >(Tektronix UTek V for the 88000 has flex-names and is 3.2 based). >Noone has done it for the 386 that I know of. > ESIX V.3.2.D has the berkeley fast file system, allowing greater than 14 character file names.... but you don't want to use it because some of the file system programs are broken. Unless they've fixed them and not sent out updates? -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov As of right now, I'm in charge here now... Alexander Haig. Voodoo Economics, that's what it is, voodoo economics. George Bush
cpcahil@virtech.uucp (Conor P. Cahill) (01/30/91)
In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >can anyone explain why there's the 14 character limitation in filenames >(11 + 3 for extension) in interactive unix? The limitation is 14 characters. Not 11 + 3 (in fact if you want an extension it is 11+2 because the period counts as one of the precious 14 characters). This is standard System V Rx where X < 4.0. With System V R4.0 you get 255 byte file names on UFS file systems. Interactive has announced that SVR4 will be shipping (as a developers release) in April. Dell, UHC and Microport have SVR4 shipping today. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
sef@kithrup.COM (Sean Eric Fagan) (01/30/91)
In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >can anyone explain why there's the 14 character limitation in filenames >(11 + 3 for extension) in interactive unix? It is *not* 11+3. It is 14. Period. Note that touch abcdefghik.lmn (which is 11, '.', 3) would not create the file would think. In standard SysVrX, where X is less than 4, there is a limit of 14 characters for filenames. In those filenames, any character, with the exceptions of nil (0x00) and '/', are permissable. (As oppposed to BSD, which still, I believe, has the limitation that only characters with the high bit clear are valid.) >is this common for all 386 based unices? Uhm. Uhm. Eek. For all SysVr3.2 '386 unices, yes. Some have added the extensions necessary for longer filenames, although there is a *lot* of trivial things that most vendords don't cover. ESIX, in particular, I believe has a version of 3.2 that allows a BSD-style filesystem. For SysVr4, the "limitation" isn't there; there is, instead, a limit of 255 characters. >is this limitation likely to be overcome anytime soon? Yes. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
stevewa@upvax.UUCP (Steve Ward) (01/30/91)
This is somewhat off the sysv386 path, but: In article <20711@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >Overcome in System V release 4. It *can* be done in System V.3.2 >(Tektronix UTek V for the 88000 has flex-names and is 3.2 based). I suspect this is because Tek used the Berkley FFS for UTek/V. My inside sources tell me the OS development for the XD88 was done on Tek 4317/19 workstations, which run "old" UTek, a Berkely 4.2 variant. It would have been perfectly logical for them to adopt the Berkely FFS, and just plug the disks drives into the new machine for testing. It is interesting to note that while UTek/V has the advanced file system in all other respects it is quite probably the most vanilla system V.3.2 OS I've ever worked on (eg, while 'vi' is available, 'more' is not...sure gets difficult to remember to type 'pg' instead of 'more'...). >Noone has done it for the 386 that I know of. I thought ESIX had a Berkely FFS...does it have the 14 character limit? While I do agree that the limit is silly, and should be done away with, it is a well known and documented limitation that developers should be keeping in mind if they want their software to be portable. Steve -- | Steve Ward Jr. appears courtesy of | stevewa@upvax.UUCP | | Univ. of Portland, Portland, OR | !tektronix!upvax!stevewa | | (insert disclaimer here) | upvax!stevewa@tektronix.TEK.COM | | --If all else fails, try: tektronix.TEK.COM!upvax!stevewa@uunet.uu.net |
geoff@Veritas.COM (Geoffrey Leach) (01/30/91)
From article <290@sps.com>, by arm@sps.com (Annette Myjak): > can anyone explain why there's the 14 character limitation in filenames > (11 + 3 for extension) in interactive unix? Its a consequence of how the directory file is organized. Use 'od -c' on the '.' file in a directory to see how it looks. > is this common for all 386 based unices? For those based on svr3 (or v7, for that matter). The bsd file system has a different orginization. Vendors that do their own os work have the option of changing it, of course. > is this limitation likely to be overcome anytime soon? SVR4 provides both the SVR3 and BSD file systems. When the file system is created, you get to choose. The possibility of other file system types being added also exists. > enquiring minds want to know! (this limitation is making it difficult > to port a fairly extensive software system.) The irony of it all is that as long as the possibility of short names exists, everyone should operate as if long names didn't. But of course, that wont happen.
ken@dali.gatech.edu (Ken Seefried iii) (01/31/91)
In article <1154@upvax.UUCP> stevewa@upvax.UUCP (Steve Ward) writes: >This is somewhat off the sysv386 path, but: >In article <20711@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >>Overcome in System V release 4. It *can* be done in System V.3.2 >>(Tektronix UTek V for the 88000 has flex-names and is 3.2 based). > >I suspect this is because Tek used the Berkley FFS for UTek/V. My inside >sources tell me the OS development for the XD88 was done on Tek 4317/19 >workstations, which run "old" UTek, a Berkely 4.2 variant. It would have >been perfectly logical for them to adopt the Berkely FFS, and just plug >the disks drives into the new machine for testing. Yes. UTek V has FFS. Flex-names, sym-links and all. However, one simply doesn't drop FFS on top of System V and rock-n-roll. Take a walk throught the System V.3.2 source some time and see how many commands are hardwired with the assumption that filenames are 14 chars long. This was hashed out in some detail on (i think) comp.arch some months ago. >It is interesting to note that while UTek/V has the advanced file system >in all other respects it is quite probably the most vanilla system V.3.2 >OS I've ever worked on (eg, while 'vi' is available, 'more' is not...sure >gets difficult to remember to type 'pg' instead of 'more'...). $ ln /bin/pg /bin/more I've got one on my desk at work. Bizarre machine. Damn shame they couldn't have been developed to maturity. > >>Noone has done it for the 386 that I know of. > >I thought ESIX had a Berkely FFS...does it have the 14 character limit? > So it seems. But someone also indicated that it isn't yet fully functional. I rather suspect that's cause of hardwired limits in the utilities. Finally, in the end, we actually got back on the topic....;') -- ken seefried iii "A sneer, a snarl, a whip that ken@dali.cc.gatech.edu stings...these are a few of my favorite things..."
jrh@mustang.dell.com (James Howard) (01/31/91)
In article <290@sps.com>, arm@sps.com (Annette Myjak) writes: > can anyone explain why there's the 14 character limitation in filenames > (11 + 3 for extension) in interactive unix? It is not 11+3, but 14 characters period. (Which would map to 11+2 anyway, including the period). > is this common for all 386 based unices? No, primarily s5 file systems. BSD or SVR4 'ufs' file systems support up to 255 character filenames. It is not related to the actual UNIX revision so much as the file system type itself. For example, SVR4 UNIX still has 14 character filename limits for s5 file systems, which it must for compatibility reasons. > is this limitation likely to be overcome anytime soon? see above.. > annette myjak > arm@sps.com James Howard Dell Computer Corp. !'s:uunet!dell!mustang!jrh (512) 343-3480 9505 Arboretum Blvd @'s:jrh@mustang.dell.com Austin, TX 78759-7299
martin@mwtech.UUCP (Martin Weitzel) (01/31/91)
In article <290@sps.com> arm@sps.com (Annette Myjak) writes: >can anyone explain why there's the 14 character limitation in filenames >(11 + 3 for extension) in interactive unix? Small note: This is not quite correctly stated. There's no such thing like an "extension" in the UNIX filenames. If you do it in the common way, i.e. use a dot to separate filename and extension, this costs you one extra char, hence you have 10+3 (or 11+2 or 12+1 or 14+0 or ...) But guess what: Some days ago I prepared a floppy on my UNIX system for use with some other OS, hmm, I just can't remember the name, what was it ... hmmm, anyway, it's a quite common OS, in much broader use than UNIX and most people who have used it and then go over to UNIX find this other system so much more friendly and easier to use. (If I could only remember the name of that OS, it's so common!) Anyway, I found that I couldn't copy a file named "hello-krc.c" onto said floppy because this other system had only 8+3 characters for filename + extension. Since so many people keep telling that the other system is much easier to use than UNIX, I suppose 14 characters in a UNIX filename are in fact a bad choice - it simply makes filenames too long to keep them in mind. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
s900387@minyos.xx.rmit.oz.au (Craig Macbride) (01/31/91)
jrh@mustang.dell.com (James Howard) writes: >In article <290@sps.com>, arm@sps.com (Annette Myjak) writes: >> can anyone explain why there's the 14 character limitation in filenames >> (11 + 3 for extension) in interactive unix? >It is not 11+3, but 14 characters period. (Which would map to 11+2 anyway, >including the period). Actually, it's 16-2, if anything. SysV Unix likes directories which have 16- byte entries for files, which are split into 2-byte unsigned inode number and 14-byte file name. As you pointed out, BSD uses up to 255 chars, by storing each entry in a variable length. -- _____________________________________________________________________________ | Craig Macbride, s900387@minyos.xx.rmit.oz.au | Reality is for people who | | Only the equipment belongs to Victoria Uni. | can't handle science fiction.| | of Technology (RMIT); The opinions are mine. |______________________________|
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/01/91)
As quoted from <20711@hydra.gatech.EDU> by ken@dali.gatech.edu (Ken Seefried iii): +--------------- | In article <290@sps.com> arm@sps.com (Annette Myjak) writes: | >can anyone explain why there's the 14 character limitation in filenames | >(11 + 3 for extension) in interactive unix? | | Cause AT&T is brain dead? Most all Version 7, System III and System V | based Unixes have a 14 character filename limit (11+3? Where'd you | get that?). Posix has also followed this silliness... +--------------- "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 names (but don't want to decrease that size, there *is* a tradeoff here), the 30-plus-character names I've seen in use on some BSD systems don't appeal at all. (To those who complain, as they did last time, that the 14-char limit means you can't encode a date in a filename: information is suppoosed to be stored *inside* files, not in their filenames! And "910131193506" fits into a filename if you absolutely *must* store the date in the filename for some reason. (Personally, if I want to locate a file quickly according to some attribute like that, I'll use an index file. It's often faster, too.)) ++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
libove@libove.det.dec.com (Jay Vassos-Libove) (02/02/91)
Actually, though Brandon complains that long filenames are a pain to type, a good shell can take care of that... I happily swipe fifty and more character filenames in to a command line by punching escape every now and then and letting my ksh or enhanced csh or enchanced sh find the file on disk and complete the filename, or by punching ^D and having the shell print out possible completions for me. Besides, just because you can have longer filenames doesn't mean you have to use them. Why turn down functionality? I hate it when bison tries to create ">8 character filename".output files and fails under SysVr3, and when patch tries to generate "14 character filename"# or ~ and fails... etc. -- Jay Vassos-Libove libove@libove.det.dec.com Digital Equipment Corporation decwrl!libove.det.dec.com!libove Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine! Farmington Hills, Michigan and D.E.C. Can't have 'em!
peter@ficc.ferranti.com (Peter da Silva) (02/02/91)
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 > names (but don't want to decrease that size, there *is* a tradeoff here), the > 30-plus-character names I've seen in use on some BSD systems don't appeal at > all. 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? And if you do go to a more complex form, why not do hashed directories or trees and really get some speedup in namei? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
cpcahil@virtech.uucp (Conor P. Cahill) (02/02/91)
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 >names (but don't want to decrease that size, there *is* a tradeoff here), the >30-plus-character names I've seen in use on some BSD systems don't appeal at >all. I don't like humongous names either, but 14 is a bit too short. Especially when you consider that two are lost for the typical source file extension and another two are lost for the source code control system (either SCCS or RCS) - thereby leaving only 10 characters for the file name. This I have found to be a little too short sometimes, but like anything else you can live with it. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/07/91)
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. ++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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/07/91)
As quoted from <1991Feb01.231125.16323@virtech.uucp> by cpcahil@virtech.uucp (Conor P. Cahill): +--------------- | 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 don't like humongous names either, but 14 is a bit too short. Especially | when you consider that two are lost for the typical source file extension | and another two are lost for the source code control system (either SCCS | or RCS) - thereby leaving only 10 characters for the file name. This I have | found to be a little too short sometimes, but like anything else | you can live with it. +--------------- The solution to the source control system problem is to drop the business of using prefixes/suffixes and just use separate directories. ".vcsdb/foo.c". ++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
chip@tct.uucp (Chip Salzenberg) (02/12/91)
According to rcd@ico.isc.com (Dick Dunn): >allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >> ... drop the business of using prefixes/suffixes and just use >> separate directories. ".vcsdb/foo.c". > >No, that's not a solution, unless you're in an isolated corner of the world >where you can use your own tools (or customized tools) ... So modify RCS 5.5 -- it's available as source. >... I was pointing out that you can't deal with enormously long file names >by having some magical shell that does filename completion. It may work in >a small corner of the world, but it doesn't generalize. So use Bash -- it's available as source.
david@twg.com (David S. Herron) (02/13/91)
In article <1991Feb02.232049.17438@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >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 >>names (but don't want to decrease that size, there *is* a tradeoff here), the >>30-plus-character names I've seen in use on some BSD systems don't appeal at >>all. I generally don't personally use file names more than about 20-30 characters. Things like the <ESC>-to-complete-file-names help a lot in that regard ... Looooooong file names *do* give the possibility for software to use all that extra room for expansion in interesting ways. The reason you might want to put data into file names are for things like using the file system as an index to a data base. No I don't have any software around which does that. But it's nice to know that it can be done, no? Supporting FLEXNAMES in the file system is useful in exactly the same way as putting FLEXNAMES in the compiler is. What I wanna know is why there should be a limit to file name length in the first place? -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- MS-DOS ... The ultimate computer virus.
fitz@wang.com (Tom Fitzgerald) (02/13/91)
> As quoted from peter@ficc.ferranti.com (Peter da Silva): > +--------------- > | Since just doubling the size > | of a directory entry would give you 30 character filenames, why bother with > | complicated stuff like the BSD system? > +--------------- Because just doubling the size of the directory entry would also waste lots more space, and double the number of disk accesses it takes to search a directory. BSD directory entries often use *less* space than SysV, since filenames are shorter than 8 characters often enough. (Consider a whole /usr/spool/news hierarchy frinstance). allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: > 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. Just because you can use 255 character filenames doesn't mean you *have* to. Sometimes real long filenames are useful, for document names (check out the internet draft documents on an archive that has them) or for multiple archived versions of things. I'm tired of having to encode a program name, version number, patchlevel and packaging info into 14 characters, but that's still better than creating a whole directory hierarchy for one file. I think BSD won with this one. It's an old principle, don't impose *any* unnecessary restrictions on the user. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
peter@ficc.ferranti.com (Peter da Silva) (02/14/91)
In article <1991Feb11.072316.193@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: > No, that's not a solution, unless you're in an isolated corner of the world > where you can use your own tools (or customized tools) instead of using the > common ones. For very many sites, this is just not a choice. Hacker solution: adb -w all the "sccs" tools and change "s." to "s/", then wrap them in scripts that make sure the "s", "p", etc... directories exist. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (02/14/91)
In article <b0roaa.iqi@wang.com> fitz@wang.com (Tom Fitzgerald) writes: > Because just doubling the size of the directory entry would also waste lots > more space, and double the number of disk accesses it takes to search a > directory. Before deciding this is such a big deal, how about checking on the actual results of this? You spoke of /usr/spool/news: % find /usr/spool/news -type d -print | xargs ls -ds | awk ' BEGIN {x=0} {x=x+$1} END {print x}' 1700 % 1700 blocks in a worst-case file system. That's under a meg, and undoubtedly includes lots and lots of holes. Double that and you're under 2 meg. That's not even a day's news feed. BSD wastes more space than that on sendmail and friends. And more time reading all those fragments for the usual case directories. > I'm tired of having to encode a > program name, version number, patchlevel and packaging info into 14 > characters, but that's still better than creating a whole directory > hierarchy for one file. Why? How often is it just one file? Why clutter up your directory like that? program/version[/partx] program/version/patchy[/partx] Deep directory trees help make it easier to find stuff. Shallow ones hide things in the mess. > I think BSD won with this one. It's an old principle, don't impose *any* > unnecessary restrictions on the user. Or unnecessary complexity on the system. If you're going to go to this extent why not hash the directory and really get some speedups in lookup? If you're going to break things, break 'em *good*. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
ronald@robobar.co.uk (Ronald S H Khoo) (02/14/91)
chip@tct.uucp (Chip Salzenberg) writes: > So modify RCS 5.5 -- it's available as source. He doesn't need to. RCS 5.5 *already* supports impoverished filename capability mode of usage. As quoted from rcs-5.5/README: +---------- | Normally, RCS file names contain `,', which is outside the Posix portable | filename character set; but in impoverished Posix environments, you can | compile RCS so that the RCS file for Foo is named just RCS/Foo. +---------- -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
dmckeon@hydra.unm.edu (Denis McKeon) (02/17/91)
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
rcd@ico.isc.com (Dick Dunn) (02/17/91)
dmckeon@hydra.unm.edu (Denis McKeon) writes: > 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). [then goes on to describe a method] Problem is that this isn't compatible with either of the existing, common approaches. If you're concerned about seriously backward compatibility, you probably want to stay with the AT&T approach. The BSD method doesn't cost much in efficiency, so if you want long names it's the way to go. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) (02/21/91)
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