Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!pawl!shadow
From: shadow@pawl.rpi.edu (Deven T. Corzine)
Newsgroups: comp.sys.amiga.tech
Subject: Re: An IFF-based filesystem? (Re: Why do you need metaphor?)
Message-ID: 
Date: 18 Aug 89 14:05:39 GMT
References: <7570@cbmvax.UUCP> <440@xdos.UUCP> <1417@bnr-fos.UUCP>
	<15863@watdragon.waterloo.edu> 
	<15892@watdragon.waterloo.edu>
Sender: usenet@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY
Lines: 84
In-reply-to: rtczegledi@crocus.waterloo.edu's message of 13 Aug 89 19:58:50 GMT


Richard> Something that I feel would be very useful (not to mention
Richard> nice) is to give the amiga the ability to put 'files' under
Richard> 'files'.  Waterloo Port does something like that.

Deven> 4 months ago, I posted to comp.sys.amiga.tech about this very
Deven> idea, albeit somewhat more thought out.  I'm afraid I don't
Deven> have a copy of the article I posted; only replies to it.  (I
Deven> have all articles I've posted since 6/28/89.)  The article I
Deven> posted was "Subject: An IFF-based filesystem?", posted to
Deven> comp.sys.amiga.tech, message ID
Deven> .  If anyone has a
Deven> copy of the article, please email it to me?

Richard> I can think of a few problems with your idea.  Most are 'how
Richard> 'ard is it to implement and have work effectively' type.  The
Richard> main drawback to your iff based file system is that the
Richard> executable will have to modify itself, thereby messing up
Richard> many resident/ares/rez type programs.

No, you misunderstood.  The *loader* will use a different format than
LoadSeg() does, but it would be able to be loaded and installed in a
resident list.  (maybe not with the Resident and Ares programs
specifically, but you would be able to do it.)

Richard> Also, every single last program for the amiga will essentialy
Richard> have to be re-written.  Now, if I left it at that, you would
Richard> mail me saying, "it would all be handled by the os, and
Richard> transparent to the software".

True.  :-)

Richard> But what about software like the (which I can not live
Richard> without) disksalv, and things like BAD (I like it), which
Richard> think they 'know' about the file systems.  They will probably
Richard> have to go.

They could still be used on AmigaDOS disks.  I would probably write a
utility similar to disksalv, (and also an undelete utility) and I have
no idea what BAD does.

Richard> And the size/complexity of the OS might just be too much to
Richard> handle.

An unknown, but it doesn't seem like it would need to be too bad.

Richard> With a simple files under files approach like I mentioned,
Richard> the os would not have to be significantly changed.  A file
Richard> could be treated like a directory, and you could directly
Richard> load files/under the main file.

I'm already looking at rewriting major pieces of the OS.

Richard> It's sort of like directories being files as well.  The
Richard> advantages would be numerous.  Hard drive maintenance,
Richard> software instalation, and the general look of the system
Richard> would be pretty great.

I've also considered the approach of all filesystem objects being both
files and directories.  How to integrate it, I'm not sure.  If you do
a cp, does it only copy the file portion, or the file and the entire
directory subtree?  Should rm act on the file or both?  etc.

Richard> When you mention, 'my system was a lot more thought out than
Richard> yours', you obviously did more thinking about your method
Richard> (which is neat, cool, and rather boffo, but tough to
Richard> implement).  The system I'm refering to is already sort of
Richard> implemented in other operating systems.  It would offer about
Richard> the same functionality as your system too (I think).  Also, I
Richard> have used this files under files approach, and find it to be
Richard> quite flexable powerful, and fun.

IFF is recursive.  Any IFF file can be a part of another.  IFF is
already somewhat established as a standard file format on the Amiga,
and integrating that at the system level could help promote that.  It
is an excellent format, well thought out and well executed.  And it
can be extended beyond graphics and sound...

Deven
--
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2214 12th Street, Troy, NY 12180       Phone:  (518) 271-0750
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.