Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (Dr. R. Chandra)
Newsgroups: comp.unix.wizards
Subject: Re: Long filenames (was: What kinds of things would you want in the GNU OS?)
Message-ID: <6388@cs.Buffalo.EDU>
Date: 9 Jun 89 00:09:09 GMT
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@marvin.cs.buffalo.edu (Dr. R. Chandra)
Organization: SUNY/Buffalo Computer Science
Lines: 60

First I wish to respond to some of the letters I have received and
some postings about how I don't favor symln.  The bulk of all this is
complaining about linking across filesystems.  Yes, true, I knew that,
but as long as filesystems can be umounted and remounted in different
spots, this can cause inconsistentcies.  I still am unsure about the
efficiency of such constructs, which was the discussion of the
original post.

My main gripe is the fact that I wished (and knew it
probably wouldn't work but I tried it anyway) that a symln in my home
dir would hold some data in /tmp/john after its reference was trashed
due to a cleanout of /tmp, without taking up my quota.  Dream on I
thought and dream on I would have to do.  Now if there were some way
to still keep those referenced inodes and disk blocks used, that would
be wonderful.  But alas, it would probably instantly be added on to my
quota the instant it was the last link to the file.

barnett@crdgw1.ge.com (Bruce G. Barnett) wrote:
.
.
.
=>The filename contains all of the information needed. I don't have to
=>search another file to determine the name for the archive.

Another plus not necessarily stressed enough is that the information
is current, as long as the system "survives" to write everything to
disk.  A while back I wrote what amounted to a BBS for a Prime 750
using CPL for the computer science club at Erie (County) Community College,
North Campus.  I used the Primos file system to store and keep track
of almost everything so that in the event of the failure of my
program, or the failure of the system, everything would be basically
intact.  If I used my own files to keep track of everything, as many
BBS programs do, the version of what files were available in my files
and the version of what is actually there could be two totally
different things.  Although this did not totally eliminate the need
for error checking upon opening a file ferinstance, it did eliminate
the need for a utility program to go through the filesystem and update
the BBS's idea of what the real world looked like.  Perhaps the most
important part in all this is that a filing system is there to USE,
not just to store your information.  Do you want a new message area?
Simply create a new directory, and when the program goes to list the
message areas available by asking for a list of directories in that
particular subdirectory, it is there.  No need to update an "available
message area" data file.  No source code modification (if I were
stupid or inept or whatever enough to hard code the list of message
areas into the program).  (Now that I think of it, I could have slowed
things down a bit but enhanced generality by doing similar things with
the available commands list.)

Use the filesystem to its fullest advantage, just as make does by
checking the timestamps on files (oh, no...did I just reopen the
make/gnumake/nmake war?).
---
From one "super" user to another:
Where do we keep our bison and yacc?  In a zoo of course!
"Answer my question, tell me no lies.
 Is this the real real world, or a fool's paradise?" 
  -- Eric Woolfson & Alan Parsons
(Lately, I'm beginning to believe the truth is the second case.)
ugkamins@sunybcs.UUCP