Path: utzoo!utgpu!water!watmath!clyde!rutgers!mailrus!husc6!bbn!mit-eddie!uw-beaver!tektronix!tekgen!tekigm2!phils
From: phils@tekigm2.TEK.COM (Philip E Staub)
Newsgroups: comp.sys.amiga
Subject: Re: Why is there a mount but no unmount?
Keywords: mount unmount path
Message-ID: <2810@tekigm2.TEK.COM>
Date: 11 Apr 88 05:50:36 GMT
References: <4643@garfield.UUCP> <242@ssbell.UUCP>
Reply-To: phils@tekigm2.UUCP (Philip E Staub)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 77

In article <242@ssbell.UUCP> chris@ssbell.UUCP (0000-Chris Olson) writes:
>[ Death to the unbelievers!  Join me or die! -- this line for line-eaters ]
>
>Does anyone out there know of any GOOD reason that commodore
>forgot to supply an unmount command to go with the mount?
>It has burned me a few times when I needed to unmount my
>hard-drive in mid-session (say, while testing a PD program
>for trojan horses), couldn't, and had to shut down my system
>and find a boot disk which didn't mount the drive...
>
>...if there isn't a real good reason, anyone out there feel
>like:
>     a)  writing one and releasing it to the public at large?
>     b)  telling me how to go about it in nauseating detail?
>     c)  showing me where I can get the information to do it
>         myself?
>
>...and if there is a good reason, explain to me why.  Anyone
>know if unmount is in 1.3?

I'll take a stab at this one. Someone more knowledgeable than I can knock 
off the rough edges.

Imagine the following scenario: your Amiga has several processes running
which have at one time or another accessed the mounted drive in one way or
another and thereby created a lock on a diretory or file on that drive.

Let's also say that at the current time there are outstanding locks on that
drive, but you want to unmount it. How do you notify each process that the
file or directory lock on the device you are going to unmount is about to
be invalidated? Well, if I read the books correctly, there isn't any way
to do that, since resource tracking is not done in that kind of detail 
in AmigaDOS. Even if you had a linked list of outstanding locks with
pointers off to processes which created the lock, there's no way of 
guaranteeing that the process didn't die without releasing the lock.
(Again the resource tracking bit. If we kept that close tabs on locks, we 
could release all outstanding locks when a process dies. And while we're 
at it, we could free all outstanding memory allocations, and do all sorts
of other interesting things. But it just ain't there.)

Now, you may say, "Well, I'll just stop all the processes which are using that
lock and then I won't have to worry about it." What about processes which
you may have started and then forgotten about, particularly as part of your
startup-sequence? Also, I think that "path" keeps a lock on directories 
in your search path, whether that is your current directory or not. (I'm 
not certain about that, but I've always assumed that to be the case, 
since I've never been able to delete a directory which is in my search path.)

Now how about that process which had a lock on a file when the process itself
died? No way you're going to get rid of that lock. 

Bottom line is that if you're going to prevent some process from using a 
lock on a device which is no longer valid, you've got to notify the 
process somehow, and I don't think there's any way to do that.

I'm sure there are other reasons, but this is one I've always assumed was
the major factor. It would make it nearly impossible to guarantee that an 
unmount command would work all the time, or at least that it would fail in
such a way that a relatively non-technical user would be able to determine
why it failed and what s/he could (or couldn't) do about it.

>
>[+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+]
>                                           /
>     Chris Olson                          O
>     (aka, Lord Valentine,        OXXXXXXXI>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>           Electric Samurai,              O
>           & other foolishness)            \
>     (cbosgd!ohgua!ugn!ssbell!chris)

Phil

-- 
------------------------------------------------------------------------------
Phil Staub                     "I do NOT approve. I merely said I UNDERSTAND."
tektronix!tekigm2!phils                                              - Spock
phils@tekigm2.TEK.COM