lee@sed170.HAC.COM (John Lee) (01/05/90)
Currently, the "Official" way of determining the list of disk devices is to
walk down the AmigaDOS device list, looking for entries for devices that
have a non-NULL name and are resident (Task field non-zero), like this:
/* Pseudo-code */
for (devent = Device List; devent != NULL; devent = devent->next) {
if ((devent's Type is device) && (devent's Task is non-zero)
&& (devent's Name is non-zero)) {
(devent is entry for a disk device)
}
}
While this does indeed locate all disk (i.e. directory-oriented) devices,
it can also mistakenly return other devices, such as PIPE:. To illustrate
this, startup DPaint 1.3 and bring up the Load file-requester. Note that
PIPE: does not show up in the device buttons. Now exit DPaint, copy
something to 1.3's PIPE: (perhaps "run dir >PIPE:a"), let that hang and
then startup DPaint 1.3 again. Notice that PIPE: now shows up in the Load
file-requester.
My question is simple. How do you make sure you locate only disk devices,
and not merely all devices that are resident and have a name?
--John
-------------------------------------------------------------------------------
Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System
+--------+ John Lee
| HUGHES |
+--------+ ARPAnet: jhlee@hac2arpa.hac.com
Hughes Aircraft Company
The above opinions are those of the user and not of those of this machine.louie@sayshell.umd.edu (Louis A. Mamakos) (01/05/90)
In article <331@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: [ ... ] > Notice that PIPE: now shows up in the Load >file-requester. > >My question is simple. How do you make sure you locate only disk devices, >and not merely all devices that are resident and have a name? Hmm, but isn't that the whole *point* of the PIPE: device? To allow programs to use it without modificiation? I might, in another CLI, say something like: 1> zcat >PIPE:foo compressed-iff-file.Z and then load PIPE:foo from DPaint. When saving the file, I could save to PIPE:bar, and then in the other CLI say 1> compress >new-compressed-iff-file.Z -c PIPE:bar I'm sure that you can some up with similar situtations that apply to network- like devices for other purposes. It's not a bug, its a feature. Really. louie
andy@cbmvax.commodore.com (Andy Finkel) (01/05/90)
In article <331@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: > >My question is simple. How do you make sure you locate only disk devices, >and not merely all devices that are resident and have a name? Well, until the recent spate of handlers, there was a packet or two that could tell the difference between a handler and a filesystem... (and there will be a way again in the future) For now (and, if you always want to be safe) run through the list twice, and only report the devices that have matching volume nodes. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "When I was a little boy I wanted to be a fireman. Now I am." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
eberger@godot.psc.edu (Ed Berger) (01/06/90)
In article <331@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: > >While this does indeed locate all disk (i.e. directory-oriented) devices, >it can also mistakenly return other devices, such as PIPE:. To illustrate >this, startup DPaint 1.3 and bring up the Load file-requester. Note that >PIPE: does not show up in the device buttons. Now exit DPaint, copy >something to 1.3's PIPE: (perhaps "run dir >PIPE:a"), let that hang and >then startup DPaint 1.3 again. Notice that PIPE: now shows up in the Load >file-requester. Since I use Runback in my startup-sequence, Deluxe Paint III mistakingly displays NULL: as a diskdevice, as if I really wanted to load or save to there. I guess I could touch all my hardrive partitions first, and it will run out of places to put it. What is the current favorite file requestor, with source Code? I'll need one for some programs I'm working on, and I want to avoid odd behaviors like this... -Ed Berger eberger@b.psc.edu >
a464@mindlink.UUCP (Bruce Dawson) (01/06/90)
What do you mean 'check for an environment vector'? There seem to be so
many different ways of finding out whether a device is a disk or not (I've seen
three in the last few days), I wonder which is the best.
Of course this also brings up the issue of what actually should be
displayed in a file requester device list. Should assigns be displayed (it can
be really handy if they are). Should the drive name or the volume name be
displayed, or both?
.Bruce.cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/06/90)
In article <331@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: >My question is simple. How do you make sure you locate only disk devices, >and not merely all devices that are resident and have a name? Check for an ENVIRONMENT vector. Or send an ACTION_DISK_INFO packet to the Task you found and see if it knows what to do with it. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/06/90)
In article <9223@cbmvax.commodore.com> (Andy Finkel) writes: >For now (and, if you always want to be safe) run through the list >twice, and only report the devices that have matching volume nodes. Uh Andy, there is this problem that if there isn't a disk in the floppy drive you would never put it's button up on the screen using your method no? So people running DPAINT from the ram disk without having any floppies in drives would just get RAM: ? Hmmm, looks a little weak to me. Lets just say in the documentation "Well, we can't be totally sure that every button we put up is a disk drive, but we guarantee that all of your disk devices will be up there. Just as soon as C/A gives us the real answer we will fix it." On another note (* * * D E V E L O P E R A L E R T * * *) If you are counting on the device name such as DH0: being only three characters then you are in for a RUDE suprise when people like MicroBotics let you set the names of the devices to things like HardDisk0: or even Sources:. Be aware that this can (and does) happen, and your file requesters will live a happier life. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
ridder@elvira.enet.dec.com (Hans Ridder) (01/06/90)
In article <129936@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <9223@cbmvax.commodore.com> (Andy Finkel) writes: >>For now (and, if you always want to be safe) run through the list >>twice, and only report the devices that have matching volume nodes. > >Uh Andy, there is this problem that if there isn't a disk in the >floppy drive you would never put it's button up on the screen using >your method no? So people running DPAINT from the ram disk without >having any floppies in drives would just get RAM: ? What is the purpose of putting up a button when there is no disk in the drive? There's nothing to read from or write to.... I have always thought that file requesters shouldn't be putting up *drive* buttons, they should be putting up *volume* buttons. This would make network filesystems more transparent (to applications) too. Also, I'd be inclined to use a *list* of volumes rather than buttons, so that you don't have to worry about running out of room for buttons in your requester. Not trying to flame...just my point of view. -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
gilmore@vms.macc.wisc.edu (Neil Gilmore) (01/07/90)
In article <570@shodha.dec.com>, ridder@elvira.enet.dec.com (Hans Ridder) writes... >What is the purpose of putting up a button when there is no disk in >the drive? There's nothing to read from or write to.... What is the purpose of putting up a volume buttin when that disk isn't in the drive. There's nothing to read from or write to.... >I have always thought that file requesters shouldn't be putting up >*drive* buttons, they should be putting up *volume* buttons. This >would make network filesystems more transparent (to applications) too. How would you then be able to access a volume not currently mounted? Having the drives allows you to put a disk in, then call the drive to access the volume. >Also, I'd be inclined to use a *list* of volumes rather than buttons, >so that you don't have to worry about running out of room for buttons >in your requester. A good idea, but there must be a way to access floppy volumes not currently known by the system. The drive buttons are quite useful for floppys, less so for hard disks and networks, which tend to be always mounted and have potenrially several volume names per physical device. >Not trying to flame...just my point of view. And mine. >-hans +-----------------------------------------------------------------------+ | Kitakaze Tatsu Raito Neil Gilmore internet:gilmore@macc.wisc.edu | | Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 | | Middle Kingdom Madison, Wi | +-----------------------------------------------------------------------+
tlimonce@drunivac.uucp (01/07/90)
In article <2924@dogie.macc.wisc.edu>, gilmore@vms.macc.wisc.edu (Neil Gilmore) writes: > A good idea, but there must be a way to access floppy volumes not > currently known by the system. The drive buttons are quite useful for > floppys, less so for hard disks and networks, which tend to be always > mounted and have potenrially several volume names per physical device. Whenever you get a DISKCHANGE through the input.device food-chain you could re-scan the system list. Then your list would be acurate (valid selections only) and user-proof (can't select something that shouldn't be selected). One school of thought on UI's is that the user should only be able to select options that work(*1). Of course, with the DISKCHANGE message, a dynamic display is possible. If the user really, really wants to use a device that wouldn't be on the list (*2) he/she can use the keybaord and enter it into the string gadget. I hope this feature is in the 1.4 filerequester. -Tom (*1) -- For example, in pull-down menus the hazy options can't be selected. (*2) -- For example, the common Usenet complain about GUI's that "I know what I'm doing better than the @*#&$^ computer!" --- Tom Limoncelli The computer industry should spend more time in front of tlimonce@drew.uucp their computers. Remember when "Look & Feel" tlimonce@drew.Bitnet was what you tried to do on a date? limonce@pilot.njin.net NOTE: REPLY to this message doesn't work (yet), please use tlimonce@drew.uucp
new@udel.edu (Darren New) (01/09/90)
In article <2924@dogie.macc.wisc.edu> gilmore@vms.macc.wisc.edu (Neil Gilmore) writes: >In article <570@shodha.dec.com>, ridder@elvira.enet.dec.com (Hans Ridder) writes... >>I have always thought that file requesters shouldn't be putting up >>*drive* buttons, they should be putting up *volume* buttons. This >>would make network filesystems more transparent (to applications) too. > >How would you then be able to access a volume not currently mounted? >Having the drives allows you to put a disk in, then call the drive to >access the volume. You do it the same way that Workbench does it. When a disk is inserted, add that volume name to the list of available volumes. Actually, I think one of the early versions of DPaint or DVideo did something very similar to this, and I really liked it. On a side note, I really hate the TurboSilver file requestor. It puts up the names unsorted, then leaves them unsorted until you scroll, which rearranges all the names into order. If you're going to sort names, sort during insertion, not after the scan is complete! That's like rearranging all the windows every time you resize any one. -- Darren
ridder@elvira.enet.dec.com (Hans Ridder) (01/09/90)
In article <2924@dogie.macc.wisc.edu> gilmore@vms.macc.wisc.edu (Neil Gilmore) writes: >In article <570@shodha.dec.com>, ridder@elvira.enet.dec.com (Hans Ridder) writes... >>What is the purpose of putting up a button when there is no disk in >>the drive? There's nothing to read from or write to.... > >What is the purpose of putting up a volume buttin when that disk isn't >in the drive. There's nothing to read from or write to.... I didn't say you should or shouldn't put up volume buttons for volumes not in any drives, did I? On a technical level, you have two options. The first is to put up a button for every volume entry in DOS's list. The second is to put put up a button only for volumes currently mounted (in a drive). Either is do-able. I would probably choose the first option. What's the point of your question? >A good idea, but there must be a way to access floppy volumes not >currently known by the system. The drive buttons are quite useful for >floppys, less so for hard disks and networks, which tend to be always >mounted and have potenrially several volume names per physical device. As others have pointed out, using Intuition (or the input.device) it is quite possible to determine when floppies are inserted into drives, and thus they would be mounted and visible to any file requester. With this method you can easily write to any disk you want to stick into a drive (floppy, CD ROM, cartridge disk, whatever they think of next.) Something I thought of a while back was that a file requester could *automatically* select a volume when it was inserted. The assumption would be that if you just stuck it in, you probably want to access it. I havn't seen any applications doing this, so I don't know if this would be more annoying than not. I'd have to try living with it for a while to see if it drove me bats. Just an idea.... -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
lee@sed170.HAC.COM (John Lee) (01/10/90)
In article <1990Jan5.132842.11132@haven.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >In article <331@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: >[ ... ] >> Notice that PIPE: now shows up in the Load >>file-requester. > >Hmm, but isn't that the whole *point* of the PIPE: device? To allow programs >to use it without modificiation? I might, in another CLI, say something like: [...] >I'm sure that you can some up with similar situtations that apply to network- >like devices for other purposes. > >It's not a bug, its a feature. Really. > >louie Well, yes and no. True, PIPE: is designed to be used as a file sink and source, but I'm looking only for devices that have filesystems, i.e. supports directory structures. While PIPE theoretically could support directories (and then *should* appear in the file requester), it currently does not and if you try to select the PIPE: button in DPaint, you just get the directory of DPaint's default volume. Being able to 'dir PIPE:' might be neat. Perhaps someone could enhance PIPE: in the future? --John ------------------------------------------------------------------------------- Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System +--------+ John Lee | HUGHES | +--------+ ARPAnet: jhlee@hac2arpa.hac.com Hughes Aircraft Company The above opinions are those of the user and not of those of this machine.
lee@sed170.HAC.COM (John Lee) (01/10/90)
Thanks everyone! It's a shame it's not simple (yet), but then
anything worth anything rarely is. Here are the summaries of how to
find only those devices in the system device list that are disks:
(From Doug Teeter <TEETER@HUMBER.BITNET>:)
[Doug E-mailed me a bit of code for Manx C that prints out all
disk volume and their devices. Basically, it scans the device
list, queries each device with a ACTION_DISK_INFO packet, verifies
the DiskType return, and for each device, rescans the device list
for volumes, printing the device and volume name if the volume's
task is the same as the device's. E-mail me if you'd like it.]
(From Andy Finkel <andy@cbmvax.commodore.com>:)
>Well, until the recent spate of handlers, there was a packet or
>two that could tell the difference between a handler and a filesystem...
>(and there will be a way again in the future)
>
>For now (and, if you always want to be safe) run through the list
>twice, and only report the devices that have matching volume nodes.
>
> andy
(From Chuck McManis <cmcmanis@stpeter.Sun.COM>:)
>Check for an ENVIRONMENT vector. Or send an ACTION_DISK_INFO packet to
>the Task you found and see if it knows what to do with it.
>
>--Chuck McManis
--John
-------------------------------------------------------------------------------
Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System
+--------+ John Lee
| HUGHES |
+--------+ ARPAnet: jhlee@hac2arpa.hac.com
Hughes Aircraft Company
The above opinions are those of the user and not of those of this machine.doug@xdos.UUCP (Doug Merritt) (01/11/90)
In article <332@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: >supports directory structures. While PIPE theoretically could support >directories (and then *should* appear in the file requester), it currently >does not and if you try to select the PIPE: button in DPaint, you just get >the directory of DPaint's default volume. Being able to 'dir PIPE:' might >be neat. Perhaps someone could enhance PIPE: in the future? When people first started writing PD pipe devices, one of the first ones *did* support directories. Despite much enthusiastic praise from myself and others, this feature was not adopted in the PIPE: that was picked up by Commodore. I forget who the respective authors were now (or rather, do not trust my memory of who I think they were), but I'll risk a miniflame anyway: this is a perfect example of what can happen if you don't take sufficient pride in your work. When there are "competing" versions of some program, and some of them have significant nifty features that you don't bother to adopt, a huge number of people can end up being affected. I hate having to pick between using standard software (a known environment) versus enhanced software (a powerful environment) when they *could* have been one and the same. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
andy@cbmvax.commodore.com (Andy Finkel) (01/11/90)
In article <129936@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <9223@cbmvax.commodore.com> (Andy Finkel) writes: >>For now (and, if you always want to be safe) run through the list >>twice, and only report the devices that have matching volume nodes. > >Uh Andy, there is this problem that if there isn't a disk in the >floppy drive you would never put it's button up on the screen using >your method no? So people running DPAINT from the ram disk without >having any floppies in drives would just get RAM: ? Hmmm, looks a >little weak to me. Lets just say in the documentation "Well, we can't Why would you present a choice to the user than can't be selected ? As a reminder to the user that the floppy drive is present ? So the user can bring up the requester to remind him/herself that a floppy should be inserted into one of those drives ? If there isn't a floppy in the drive, you can't load or same to it...so shouldn't that selection be ghosted at least ? You don't see Workbench giving you icons for every drive you have in the system, whether or not it has a disk...why do you want file requesters to do this ? andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "When I was a little boy I wanted to be a fireman. Now I am." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (01/11/90)
In article <608@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >When people first started writing PD pipe devices, one of the first >ones *did* support directories. Despite much enthusiastic praise from >myself and others, this feature was not adopted in the PIPE: that was >picked up by Commodore. Ok, here's how I have it in my personal memory. Matt Dillon wrote the pipe: that was eventually shipped by Commodore. At about the same time, Ed Puckett wrote a pipe: that did support directories, which we all thought was a neat feature. Including Matt, who included full support for directories in his next rev, called dpipe:. I believe dpipe: came out well after Commodore had been shipping pipe: for awhile, and dpipe: had other incompatibilities with pipe: that broke some programs, hence the name change. I also seem to remember Ed's pipe: being quite a bit larger than Matt's, which may explain why Commodore shipped Matt's (or maybe they just knew Matt better). I agree with Doug that it would have been nice if Commodore had shipped a pipe: with directory support, but I'm not so sure that Matt deserves even a mini-flame for his part. Of course, by now this all ancient history... -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
groo@dsoft.UUCP (Bill Squier) (01/11/90)
In article <572@shodha.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: > >Something I thought of a while back was that a file requester could >*automatically* select a volume when it was inserted. The assumption >would be that if you just stuck it in, you probably want to access it. That's a bad idea on a multitasking machine. How would the process know that there wasn't some other application that you were inserting the disk for. Even worse, what if all applications followed this strategy? Imagine the disk contention as VirusX, ProcessA, ProcessB, ProcessC, and the validator all started reading the disk at once! Just having VirusX and the validator on my machine is bad enough. -- Bill Squier - Stevens Inst. of Tech | // "Only Amiga makes it possible" Bitnet: u93_wsquier@stevens | \X/ Internet: u93_wsquier@vaxc.stevens-tech.edu Temporary Inet (Please use until Jan. 13): ...uunet!tronsbox!dsoft!groo
doug@xdos.UUCP (Doug Merritt) (01/12/90)
In article <9523@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: > >Ok, here's how I have it in my personal memory. Matt Dillon wrote the >pipe: that was eventually shipped by Commodore. At about the same >time, Ed Puckett wrote a pipe: that did support directories, which >we all thought was a neat feature. Including Matt, who included >full support for directories in his next rev, called dpipe:. Apparently my recollection was faulty, thanks for clearing that up. I withdraw my "miniflame". I guess I should have just said: "regardless of the reasons, it sure is annoying and disappointing that the standard pipe device doesn't support directories, and I agree it'd be nice if it were upgraded." Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
scott@wilbur.uucp (Scott Beckstead) (01/12/90)
I am attempting to write a disk cataloger that merely reads the entire directory structure off the disk and for the life of me I can't seem to find anything to help me out here. Failing that is there a Catalog program that allows me to enter the disk's name after it is catalogged I have half a million EMPTY lables on the disks and I really don't want to go and change the name of every disk I have. I prefer to just lable them sequentialy with some cheap stickers and enter the disk number. I am using AZTEC C 3.6(a or b) or sozobon C any help would be appreciated. SHB
cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/13/90)
In article <901@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes: > What do you mean 'check for an environment vector'? There seem to be so >many different ways of finding out whether a device is a disk or not (I've seen >three in the last few days), I wonder which is the best. The environment vector describes the disk attached to the device, this is essentially the stuff that the Mountlist entries contain. For disk devices, the structure DevInfo (defined in <libraries/dosextens.h>) has a pointer to a FileSystemStartup message in DevInfo->dvi_Startup. Since only things with filesystems have this "message" you get only "disks". The filesystem startup message is defined in <libraries/filehandler.h> and has a pointer to an "environment vector" (now a structure in 1.3) and that vector has things like "Blocks/Track", "Heads", etc, etc. > Of course this also brings up the issue of what actually should be >displayed in a file requester device list. Should assigns be displayed (it can >be really handy if they are). Should the drive name or the volume name be >displayed, or both? >.Bruce. The question might be more accurately phrased as "What does one display as the top level for a multirooted tree structure browser?" And the answer of course varies to taste. One can think of the "Assigns" as the level above the roots of the the various file systems and the devices as being the roots above those. My "Life" file requester displays Volume names when you click "Parent" and you are at the root of the current filesystem. At the right hand column you can see which devices those volumes are currently mounted in (if you don't care to pop the disk out of DF1: to see what the volume name on it is). --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/13/90)
In article <9278@cbmvax.commodore.com> (Andy Finkel) writes: >Why would you present a choice to the user than can't be selected ? >As a reminder to the user that the floppy drive is present ? So >the user can bring up the requester to remind him/herself that >a floppy should be inserted into one of those drives ? >If there isn't a floppy in the drive, you can't load or same to >it...so shouldn't that selection be ghosted at least ? It is merely a human factors issue. If you can make the button appear like workbench makes the disk icon appear when a disk is inserted then you pretty much cover the bases. The ghosting suggestion is the best in my opinion. Leave it ghosted until a disk is inserted then un ghost it. Naive users might panic when FoobarTool doesn't "recognize" their external drive, the ghosted gadget gives them the knowledge that you know it is out there, there just isn't a disk in it yet. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
jms@tardis.Tymnet.COM (Joe Smith) (01/15/90)
In article <1990Jan12.052804.24211@wilbur.uucp> scott@wilbur.UUCP (Scott Beckstead) writes: > I am attempting to write a disk cataloger that merely reads the entire >directory structure off the disk and for the life of me I can't seem to find Check out the LS program on Fred Fish disk #236. The command "ls -R df0:" will list all the files in the top directory of the floppy, all the subdirectories, the sub-subdirectories, etc. It includes sources. You will find that, to do the cataloging right, the program cannot "merely read the directory structure off the disk". It has to recursively process each directory it finds, and every directory in those directories, and ... -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
ridder@elvira.enet.dec.com (Hans Ridder) (01/17/90)
In article <485@dsoft.UUCP> groo@dsoft.UUCP (Bill Squier) writes: >In article <572@shodha.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) >writes: >>Something I thought of a while back was that a file requester could >>*automatically* select a volume when it was inserted. The assumption >>would be that if you just stuck it in, you probably want to access it. > >That's a bad idea on a multitasking machine. How would the process know >that there wasn't some other application that you were inserting the >disk for. How about using the IDCMP messages that tell you when your window is activated or deactivated (WINDOWACTIVATED and WINDOWDEACTIVATED? Hell I don't remember). If you're the current window, then the disk is for you! >Even worse, what if all applications followed this strategy? Imagine >the disk contention as VirusX, ProcessA, ProcessB, ProcessC, and the >validator all started reading the disk at once! OK, so then there would be three processes. The validator (which will exit soon since the bit-map is valid, right?), VirusX (I don't know how long this takes to exit since I don't use it), and the active window. That won't be too bad, will it? Yes, floppies suck don't they! -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO