Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Kernel Hacks & Weird Filenames
Message-ID: <22631@bu-cs.BU.EDU>
Date: 15 May 88 17:31:11 GMT
References: <13041@brl-adm.ARPA> <4895@chinet.UUCP> <574@minya.UUCP> <24@csnz.nz> <972@cresswell.quintus.UUCP>
Organization: Boston U. Comp. Sci.
Lines: 25
In-reply-to: ok@quintus.UUCP's message of 14 May 88 08:53:10 GMT


The problem is that people are making an unnecessary distinction
between the data contained in a file name and the data contained
within the file it indicates.

A couple of years ago, in response to someone claiming that the 255
character file names of BSD are not useful I proposed a data base
design where all the data is kept in the FILE NAMES (after all, 255
bytes/record is reasonably generous under most data bases.)

The file contents would only hold other info like accessibilty,
journaling, audits etc.

The argument was that this provides a lot of integrity via
write-through and all sorts of data base tools for dealing with this
CODASYL (basically, hierarchical/tree) data base. LS becomes a way to
dump a view, 'find' is a powerful search operator, mv, rm, touch etc
are data base fundamentals, wild-cards are very useful also. The
primary data recovery tool is fsck. The inode info (stat info)
provides accessibility and ownership discipline on every record,
sounds pretty good to me.

Hey, use your imagination.

	-Barry Shein, Boston University