haitex@pnet01.cts.com (Wade Bickel) (01/31/88)
Excuse me if this suggestion is based on the lack of understanding
of some important consideration. The file system is something I use
a little, but have not really studied.
When using various File Requester systems I notice a common flaw.
If I "accept" a selection, the Requester closes. Often I am loading
a series of files into buffers or some such thing, and immeadiately
need to repeat the process. The problem is that the Requester must
read the relevant directory each and every time I call it up, which
when using a floppy is often a bit of a wait.
It seems to me that maintaining a directory of the floppies currently
in the drive(s) in RAM would solve this. Since (I assume) the system
is aware of human disk manipulations this should not be too difficult
to implement.
I've considered getting into the file system (something I should do)
and implementing something along these lines, but there are some
multi-tasking considerations that really cry for this to be done at
the O.S. level. Maybe a 1.3 enhancement?
Sorry if this is off-track or has been discussed in one of the topics
I usually skip.
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMpapa@pollux.usc.edu (Marco Papa) (02/01/88)
In article <2458@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > When using various File Requester systems I notice a common flaw. > If I "accept" a selection, the Requester closes. Often I am loading > a series of files into buffers or some such thing, and immeadiately > need to repeat the process. The problem is that the Requester must > read the relevant directory each and every time I call it up, which > when using a floppy is often a bit of a wait. The RJ Mical File Requester solves your problem. It automatically checks for disk changes and other application directed changes to decide whether the files in the file list are "up-to-date" or the directory needs to be read again. It also has a nice "Next Disk" gadget that allows very quickly to step through all your disks. We adopted RJ's File Requester in A-Talk III. The RJ File Requester is part of The Programmer's Suite, which is in one one of the Fish Disks (I forgot which one). -- Marco
mp1u+@andrew.cmu.edu (Michael Portuesi) (02/01/88)
haitex@pnet01.cts.com (Wade Bickel) writes: > When using various File Requester systems I notice a common flaw. > If I "accept" a selection, the Requester closes. Often I am loading > a series of files into buffers or some such thing, and immeadiately > need to repeat the process. The problem is that the Requester must > read the relevant directory each and every time I call it up, which > when using a floppy is often a bit of a wait. > > It seems to me that maintaining a directory of the floppies currently > in the drive(s) in RAM would solve this. Since (I assume) the system > is aware of human disk manipulations this should not be too difficult > to implement. Of course, you could simply buy a copy of FaccII and save yourself the trouble... --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "little things remind me of you...cheap cologne and that damn song too!" --The Flirts, "Jukebox"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/01/88)
> It seems to me that maintaining a directory of the floppies currently > in the drive(s) in RAM would solve this. Since (I assume) the system > is aware of human disk manipulations this should not be too difficult > to implement. This is what commercial programs like FACC do for you... Cache floppy data. Still, it is relatively easy for an application to do its own directory caching. Simply remember the directory you read in, and only rescan if it has been modified (by looking at the timestamp on the directory). -Matt
haitex@pnet01.cts.com (Wade Bickel) (02/03/88)
mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >haitex@pnet01.cts.com (Wade Bickel) writes: > >> When using various File Requester systems I notice a common flaw. >> If I "accept" a selection, the Requester closes. Often I am loading >> a series of files into buffers or some such thing, and immeadiately >> need to repeat the process. The problem is that the Requester must >> read the relevant directory each and every time I call it up, which >> when using a floppy is often a bit of a wait. >> >> It seems to me that maintaining a directory of the floppies currently >> in the drive(s) in RAM would solve this. Since (I assume) the system >> is aware of human disk manipulations this should not be too difficult >> to implement. > >Of course, you could simply buy a copy of FaccII and save yourself >the trouble... Yes, I could buy FACC and it would speed up my floppy accesses, but this does not help users' of code I'm writing. I can retain the data myself, but was hoping C= might include this feature in 1.3 or 1.4. Seems the algorithm should go something like this: 1) Set up some structures to support retaining of directories. 2) Add code to the system so that directory listings are routed through new/custom routines. 3) When an access is attempted the drive's status is checked. a) If the disk's directory has allready been read, return it. b) If the disk's directory has not been read read and return it, and retain it in the structures (dynamic or quasi-dynamic allocations, or course). It would also be nice to retain directories of disks which have been removed, as an option. In order to avoid interferance from unknown disk accesses, I assume the datestamp field should be checked to determine if the directory has been read? Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
peter@nuchat.UUCP (Peter da Silva) (02/09/88)
In article <2458@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > When using various File Requester systems I notice a common flaw. > If I "accept" a selection, the Requester closes. Often I am loading > a series of files into buffers or some such thing, and immeadiately > need to repeat the process. The problem is that the Requester must > read the relevant directory each and every time I call it up, which > when using a floppy is often a bit of a wait. Use my "instant application" file requestor, which not only doesn't close on a selection, but it also doesn't automatically scan the directory: you can run it just by typing in the file names if you know them and never wait for a directory scan. You can define a bunch of different functions to receive the file names, selectable from a menu. And it looks pretty. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.