chris@ssbell.UUCP (Chris Olson) (04/09/88)
[ 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?
[+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+]
/
Chris Olson O
(aka, Lord Valentine, OXXXXXXXI>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Electric Samurai, O
& other foolishness) \
(cbosgd!ohgua!ugn!ssbell!chris)phils@tekigm2.TEK.COM (Philip E Staub) (04/11/88)
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
page@swan.ulowell.edu (Bob Page) (04/11/88)
It's not trivial. In fact, it's like killing an Amiga process - since the system doesn't know all the resources the particular driver is using, it can't clean them up. In adition to getting the code out of memory, you have to deal with restoring buffers, removing file locks, mucking with the DOS device and name lists, and similar stuff. What if you already have open files on the device? You get the picture. The driver should do most of it, but there's currently no defined protocol (or DOS packet) that says 'unmount yourself.' >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 The rumored WB 1.3 release is rumored to have a program that will allow you to write-protect your hard disk partitions. If this rumor were true, you would also be allowed to supply a password when you write-lock the partition, so it could not be written to unless you gave the password (or rebooted the machine). Rumor also has it that there will be a way to UNMOUNT some devices, although I know less about this rumor than the first one. >and find a boot disk which didn't mount the drive... Several PD utilities can help, like QMOUSE (FF #49). Print some text like **** Press the left mouse button to *NOT* mount the hard disk **** and have QMOUSE in your startup-sequence to check. Based on the return value, you can tell whether or not to load the disk partition. In this scenario, by default, your HD would get mounted. Of course, I just CTRL/C CTRL/D my startup-sequence instead... ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/12/88)
: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. The unmount command would simply return an error if there were any outstanding locks ... simple as that. Apart from that, there is no reason whatsoever for not having such a command. -Matt
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/12/88)
In article <2810@tekigm2.TEK.COM> phils@tekigm2.UUCP (Philip E Staub) writes: >In article <242@ssbell.UUCP> chris@ssbell.UUCP (0000-Chris Olson) writes: >>Does anyone out there know of any GOOD reason that commodore >>forgot to supply an unmount command to go with the mount? > >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. > He goes on to suppose that these programs have obtained locks on various files on drives that you wish to unmount. What do these programs do if they wish to access the files on these now unmounted volumes? Well, they'd probably do what happens if you attempt to ask for a file on an unmounted floppy: Throw up a requester for the volume. I don't see any problem with the idea. Am I forgetting something? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
phils@tekigm2.TEK.COM (Philip E Staub) (04/13/88)
In article <5671@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: <In article <2810@tekigm2.TEK.COM> phils@tekigm2.UUCP (Philip E Staub) writes: <>In article <242@ssbell.UUCP> chris@ssbell.UUCP (0000-Chris Olson) writes: <>>Does anyone out there know of any GOOD reason that commodore <>>forgot to supply an unmount command to go with the mount? <> <>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. <> < He goes on to suppose that these programs have obtained locks on <various files on drives that you wish to unmount. What do these programs do <if they wish to access the files on these now unmounted volumes? < < Well, they'd probably do what happens if you attempt to ask for a <file on an unmounted floppy: Throw up a requester for the volume. < < I don't see any problem with the idea. Am I forgetting something? < <_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ <Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ < \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac <O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") <"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor Ok, I'll try it, then. Give me a day or two and I'll let you know what happens. Phil -- ------------------------------------------------------------------------------ Phil Staub "I do NOT approve. I merely said I UNDERSTAND." tektronix!tekigm2!phils - Spock phils@tekigm2.TEK.COM
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article ... phils@tekigm2.TEK.COM (Philip E Staub) writes: > In article <242@ssbell.UUCP> chris@ssbell.UUCP (0000-Chris Olson) writes: > >Does anyone out there know of any GOOD reason that commodore > >forgot to supply an unmount command to go with the mount? > 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? You don't. Just as you can't remove a file that's got locks on it, you don't let anyone unmount a device that's got locks on. It seems to work fine for UNIX. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
phils@tekigm2.TEK.COM (Philip E Staub) (04/14/88)
In article <6090@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >It's not trivial. In fact, it's like killing an Amiga process - since ^^^^^^^^^^^^^^^^ Boy you're not kidding. I'm playing with it now and it's a little like trying to get the worms back in the can: the only way is worm puree! >the system doesn't know all the resources the particular driver is >using, it can't clean them up. In adition to getting the code out of In fact that's exactly what you have to do: each mounted disk has it's own task which must be killed. >memory, you have to deal with restoring buffers, removing file locks, >mucking with the DOS device and name lists, and similar stuff. What It also needs to remove the interrupt server and free the signal bits for that task. >if you already have open files on the device? You get the picture. >The driver should do most of it, but there's currently no defined >protocol (or DOS packet) that says 'unmount yourself.' I toyed with the idea of sending a CloseDevice to the task (to close the *unit* through the message port). But to do that you need a pointer to the i/o request and the unit structure, and I'm not sure you can get there from here. Even then there's no guarantee that the close will expunge the handler task for that unit. Well, I'm still trying. I've got a quickie program running which unlinks the mounted device, but it doesn't free up all of the resources. Well, we'll see what happens. > >..Bob >-- >Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Phil -- ------------------------------------------------------------------------------ Phil Staub "I do NOT approve. I merely said I UNDERSTAND." tektronix!tekigm2!phils - Spock phils@tekigm2.TEK.COM
FVEST@AUDUCVAX.BITNET (04/14/88)
>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? You don't, you maintain the lock just as if a disk had been removed from a 1020 drive. If the that volume is needed, the OS will display a requestor asking for volume XXX in any drive...Pop to the background CLI and mount it... or select CANCEL and the task should fail. Floyd Vest Auburn University FVEST@AUDUCVAX.bitnet {...!psuvax1!auducvax.bitnet!fvest}
andy@cbmvax.UUCP (Andy Finkel) (04/14/88)
In article <1823@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article ... phils@tekigm2.TEK.COM (Philip E Staub) writes: >> In article <242@ssbell.UUCP> chris@ssbell.UUCP (0000-Chris Olson) writes: >> >Does anyone out there know of any GOOD reason that commodore >> >forgot to supply an unmount command to go with the mount? > >You don't. Just as you can't remove a file that's got locks on it, you don't >let anyone unmount a device that's got locks on. > >It seems to work fine for UNIX. Yes this should work fine for AmigaDOS as well. However, this isn't the problem. It's resource tracking again. Only the handler itself knows what resources it has locked down, that should be returned to the system when the handler is unmounted. The solution might be to implement the ACTION_DIE packet in all existing handlers. We'll keep this in mind for the future, ok ? andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
peter@sugar.UUCP (Peter da Silva) (04/16/88)
The bottom line is: It would be easy for Commodore to add a new "REMOVE YOURSELF" packet and implement unmount that way. Even in 1.2, if they provided new drivers. It's hard for anyone else to klude up an unmount. Unless they do the same thing and convince everyone else to play along. Does everyone agree this is a pretty good summary of the situation? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
neil@amiga.UUCP (Neil Katin) (04/23/88)
I'm going to assume you mean "unload" as in unload a device handler from memory. We already have unmount: a volume goes away when no one is using it (e.g. floppies). There are two reasons why we don't have an "unload" command in amiga-dos: one political and one technical. The political reason is that TRIPOS did not have it, and the person in charge of the dos (who will remain nameless) did not think it was important enough; after all, it was a single user machine and you could always reboot. The technical reason are very sticky: it revolves around the problem of there being no access control to the dos's device list. This means that while you can add things to the list, you can never safely remove them because someone might have your device node in hand while you are removing it. This is a small window of vulnerability, but a nasty one when it happens. We live with the problem for removing aliases and volumes now, though. The other problem is that people can get a handle on the device handlers message port (via DeviceProc()). This handle is valid "forever", so you can never make a handler go away. Sorry, but that's life.