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.