ugpete@cs.buffalo.EDU (Peter Theobald) (12/01/87)
<Beware the Killer Line Eate...
..
.
.
Ross Cunniff has an great idea! Instead of trying to put all the icon
.info stuff into one file for speed (which breaks all kinds of things), Make
a file (.info.dir for instance) that contains a list of all the .info files
in a directory, or better yet a list of file pointers (sector #s) to the
.info files.
AmigaDog is VERY fast at looking up files it already knows the names
of (it can go right to them because of the hash tables) so opening a
workbench drawer is now a process of getting '.info.dir' then getting each
.info file in the list. Very fast!
Workbench would have to be changed as follows: Each time a .info file is
deleted or a new .info file is created, the .info.dir in that directory
must be updated. Note that if a .info file is merely altered the .info.dir
is still valid and doesn't have to be changed.
These changes wouldn't break any of the existing programs. Everything
would be application invisible.
_ __ ______ _
' ) ) _/_ / / / // /
/--' _ / _ __ --/ /_ _ ____/_____. // __/
/ </_<__</_/ (_ (_/ / /_</_(_) /_) (_/|_</_(_/_
Peter Theobald
SUNY/Buffalo Computer Science
csnet: ugpete@buffalo.CSNET
uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugpete
BITNET: ugpete@sunybcs.BITNETsean@ms.uky.edu (Sean Casey) (12/01/87)
In article <6888@sunybcs.UUCP> ugpete@sunybcs.UUCP (Peter Theobald) writes: > AmigaDog is VERY fast at looking up files it already knows the names >of (it can go right to them because of the hash tables) so opening a >workbench drawer is now a process of getting '.info.dir' then getting each >.info file in the list. Very fast! > Workbench would have to be changed as follows: Each time a .info file is >deleted or a new .info file is created, the .info.dir in that directory >must be updated. Note that if a .info file is merely altered the .info.dir >is still valid and doesn't have to be changed. Better yet, do the right thing and fix Amigados and associated programs so that directory accesses go as quickly as they could. Maybe we could get Commodore to hire ASDG to rewrite the thing :-). Then you know it would be fast! Sean -- -- Sean Casey sean@ms.uky.edu, {rutgers,uunet,cbosgd}!ukma!sean -- (the Empire guy) sean@ms.uky.csnet, sean@UKMA.BITNET -- University of Kentucky in Lexington Kentucky, USA -- "Inconceivable!"
louie@trantor.umd.edu (Louis A. Mamakos) (12/01/87)
Oh no, not again! The annual fix-the-workbench-by-putting-all-the-icons-in- one-file discussion. Oh well. Anyway, if you should happen to type something like, "TYPE SYS:SYSTEM/.INFO OPT H" you will, in fact, see a list of the file names which have icons in that directory. So this part is already done. Besides, you can repair this problem anyway you'd like. If you notice, the *ONLY* documented interface to the Icons that the workbench uses is by using GetDiskObject() and PutDiskObject() in icon.library. I claim that you can change the icons to work anyway you'd like, and have all well behaved programs work just fine, thank you. Personally, I'd like to see all of the icons be in one file per directory (I just had to get an my opinion in here, since this discussion is starting up again). Anyway, I hope that something is changed next time around. There's certainly a lot of room for improvement here. I'm glad that we can talk about enhancing the software rather than fixing a horrible bug (40 folders, anyone?) Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
peter@sugar.UUCP (Peter da Silva) (12/03/87)
In article <6888@sunybcs.UUCP>, ugpete@cs.buffalo.EDU (Peter Theobald) writes: > Make a file (.info.dir for instance) that contains a list of all the .info > files in a directory, or better yet a list of file pointers (sector #s) to the > .info files. Isn't this basically what the ".info" file in each directory is? It's automatically invalidated if the directory date is later than the .info date. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
michael@remsit.UUCP (Michael Gersten) (12/05/87)
In article <7795@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >In article <6888@sunybcs.UUCP> ugpete@sunybcs.UUCP (Peter Theobald) writes: >> AmigaDog is VERY fast at looking up files it already knows the names >>of (it can go right to them because of the hash tables) so opening a >>workbench drawer is now a process of getting '.info.dir' then getting each >>.info file in the list. Very fast! >> Workbench would have to be changed as follows: Each time a .info file is >>deleted or a new .info file is created, the .info.dir in that directory >>must be updated. Note that if a .info file is merely altered the .info.dir >>is still valid and doesn't have to be changed. Workbench already does this. The problem is that it usually winds up going to a new track. The system only cache's sectors that were requested, so 10 sectors (5K of data folks) gets thrown out. >Better yet, do the right thing and fix Amigados and associated programs so >that directory accesses go as quickly as they could. All you need to do is tell the trackdisk.device to cache TRACKS, not just the 5 most recent sectors. Speaking of which, C=, can we please get the 1.1 file system BACK in 1.3? You think I'm crazy? Imagine what happens when a track dies. Under 1.1 you lost one file or 11 file names. Under 1.2 you lose one file or 5 file names and 5 files. (Guess what happened to me recently?) Michael