dillon@CORY.BERKELEY.EDU (Matt Dillon) (01/27/88)
How about a file cache w/ symbolic link capability? That is, a DOS device that looks like a RAM: disk. You can do all the things a RAM: disk can do. Additionaly, you can soft-link other devices symbolically. E.G. you can soft-link C: DF0:C DF1:C DF2:C DF3:C all as CAS:C, so when you get a directory of CAS:C, you get a combined directory of everything. This allows you to PATH ADD CAS:C and have it automagically search all mounted drives. This would also be useful for combining, for instance, various remote font directories on other disks into CAS:FONTS, say. Furthermore, unlike the CLI PATH, CAS: is symbolically linked so if a specific volume is not mounted it is ignored (NO requestor). Then the cache ability: Whenever a file in CAS: is openned that refers through one of the symbolic links, download the entire file into CAS: (remember it is a RAM disk also) with a timeout... the file is automatically removed after X minutes of non-use. The volume *is* checked on an open which goes to a cached file, and the file is reloaded if the original file has a later timestamp. Note that the *feature* here is the timeout-delete capability. I don't have time to work on such a project (right now I'm working on some networking stuff), but would love to see such a device. FACC is nice and all that, but sometimes gets rid of things I don't want gotten rid of. A prime skeleton for such a device would be the example ram disk I posted a couple months back. -Matt
roch@uiucdcsb.cs.uiuc.edu (02/03/88)
Matt's CAS: file cache device sounds good, but how about letting the user select a replacement policy rather than simply using a timeout? I can forsee someone who may use something infrequently, but still want it in their cache. For example, if I am doing development, I may be accessing certain include files & the compiler only every hour or so. I'd hate to have them deleted when the cache isn't full simply because they were old. David Roch roch@b.cs.uiuc.edu