14 character limitation in filenames

[Peter da Silva]

In article <b0roaa.iqi at wang.com> fitz at 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 at ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"