Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: Links with the AmigaDOS file system
Message-ID: <4530@jade.BERKELEY.EDU>
Date: Thu, 30-Jul-87 14:28:39 EDT
Article-I.D.: jade.4530
Posted: Thu Jul 30 14:28:39 1987
Date-Received: Sat, 1-Aug-87 20:41:32 EDT
References: <1385@crash.CTS.COM> <4410009@hpcvcd.HP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 47

File system redesigners take note. Maybe some of this can wind up in
a new file system.

In article <4410009@hpcvcd.HP> charles@hpcvcd.HP (Charles Brown) writes:
<One of the nice things about Un*x, with its inodes is linking.  Is
<the Amig* file system able to do this?  I sorely miss it.

The file system as it exists doesn't support any kind of link. If you
look at the Technical Reference Manual, it's obvious why unix links
(not BSD soft links!) aren't supported.

Every block contains the disk address of the file header it belongs
to.  The file header is the closest thing to a Unix inode in the
AmigaDOS file system. Except that it's also got the files name
embedded in it.

On Unix, a file is identified by a (device, inode) pair. Directories
hold (name, inode) pairs (device being the one the directory is on).
[I know, I missed mounted file systems. Doesn't matter for this.] All
a link is on Unix is another name that points to the same inode. All
links are equivalent, none is special.

That just *can't* happen on AmigaDOS. On the other hand, a BSD soft
link could be added. Take a file header block, and insert an absolute
path *from the top of the current volume* where the data block
pointers usually go.

This leaves you with one special name - the name that has a real file
header, instead of a soft file header. Deleting the real file leaves
you with files that exist, but return errors on open.

Putting the disk address of a file header block in instead of a file
name looks possible, but creates problems if you delete the file. A
valid header landing in that block will give you headaches. Likewise,
deleting a file and then renaming another file to the old name leaves
the links dangling.

Somone want to write a replacement Open() for the Dos library to
handle soft links? Wanna watch diskdoctor or disksalve get *really*
upset when it trips over that block?

	<mike
--
But I'll survive, no you won't catch me,		Mike Meyer
I'll resist the urge that is tempting me,		ucbvax!mwm
I'll avert my eyes, keep you off my knee,		mwm@berkeley.edu
But it feels so good when you talk to me.		mwm@ucbjade.BITNET