t-jacobs@wasatch.utah.edu (Tony Jacobs) (09/02/89)
In article <1544@draken.nada.kth.se>, d88-jwa@nada.kth.se (Jon W{tte) writes: > > Re: Virtual disks (Really, delayed-action disks) > > I have two things to say about the post about "Virtual disks": > > 1) That's not virtual disks, that's just an extension of what the finder > does to off-volume volumes/windows. Multiple partitions on a single > hard disk is closer to what I'd call a "virtual disk". I came up with virtual disks because virtual memory means your creating pseudo memory by using diskspace. So Im thinking these are pseudo disks or perhaps pseudo volumes by using diskspace to simulate them. A partition on a disk is just considered a volume. Your not using diskspace to simulate a seperate disk your using it as a real disk. Your just partitioning and treating each partition as seperate volumes. There doesn't seem to me to be anything virtual about that. > > 2) It's TOO insecure. If the machine happened to go down AFTER you > dragged around a file (or deleted it) but BEFORE these actions > were updated, you'd end up having a corrupted file system and > possible loss of data. This is especially true of a machine without > protected memory... (Hear me, Apple ? :-) > > Consider the following scenario: > > The user puts in a disk, and the Mac remembers the disks directory structure. > The user ejects this disk and inserts another disk. > The user drags an icon from the last disk to the first. > The mac caches up this copy, but delays it. > The user drags the original file down the drain. > The mac caches up this action. Since the volume is on-line now, the mac > promptly erases the file, after caching in the file data to be copied. Why in the heck would you have the system erase the file??? Here the system sould mark the file to be deleted once the copy to the new location is completed succesfully. It could probably be done in such a way that if the power does go out before the copy is made what you really lose is all the cached commands to make the changes. The actual changes to the directory wouldn't be made until the changes actually took place. > The power fails... > > Or, if you tried to implement it a little safer, you could still end up > with corrupted file systems, file chains, directory entries etc. > If directory entrys for the offline volumes get screwed up SO WHAT! They just get removed and recreated if necessary. These are *NOT* two-way links or replacements for the offline directories, they are just copies to be used for informational purposes only. Sure moving files around is just informational but the pseudo directory entrys are only used as information to facilitate the moving of those files. The directories on the real volumes would always over ride the pseudo ones unless the real ones are screwed up and the user chooses to use the pseudo ones to try to repair the real ones. > I'm not saying that this doesn't happen now (It sadly does) but that there'd > be no use in increasing the chances for this to happen. > If this were as safe as I make it sound above then the problems with floppy directories getting screwed up would be eased by being able to repair the directory from the copy on the hard disk. You don't make advances in technology by being super safe and not taking any chances. First you streatch your imagination, then your work time, and then perhaps you will have streatched your reach. > Since I feel that many more people will answer this in a similar vein, I > consider this 'nuff said. I waited for a day or so before I replyed so I could answer all the replys at once, but so far no one else has come up with a "similar vein"! I really think your being a little too skeptical. I can think of a MILLION ways to make this Idea not work. The challenge is to think of the one beautiful & simple way to make it work. > > -- > This is your fortune from h+@nada.kth.se: > TANSTAAFL, rel. -- There Ain't No Such Thing As A Free Lunch The Main feature I would use here is to be able to find files. The moving and deleting and directory recovery features would be nice additions, but I don't think I would use them nearly as often as I would the find feature. I thought perhaps there would be more replys saying "yeah, that's an idea" or others like yours pointing out possible problems. I did get one reply by mail that said it is a good idea but that he thought this could be done with a seperate application. I disagree. I don't think any changes need to be made to the file system (other that those changes they are makeing for Sys7.0 like aliasing) but, only to the Finder. For this to work nice, I really believe it needs to be built into the Finder. Perhaps no one thinks much of the idea or perhaps they think theres not much chance Apple will listen. Someday when theres terabytes worth of information at peoples fingertips they will need hundred-mega-byte EERAM just to store the zillions of aliases to the real files. Speedily with Apples instant directory search techniques any file can be found and the cd from the kilo-platter cd Juke box slides a disk into place and the file is online in a matter of seconds. Text, graphics, sound, video, smell, and emotion all begin to spew from all those laser bits... *dream-mode-off* get back to work Tony. -- Tony Jacobs * Center for Engineering Design * UofU * t-jacobs@wasatch.utah.edu