home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / amiga / programm / 12837 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!rutgers!cbmvax!cbmehq!cbmden!hemmer!hemmer
  2. From: hemmer@hemmer.adsp.sub.org (Franz Hemmer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Quick ?
  5. Message-ID: <hemmer.01z3@hemmer.adsp.sub.org>
  6. Date: 28 Aug 92 08:32:45 GMT
  7. Reply-To: cbmehq!cbmden!hemmer@cbmvax.commodore.com (Franz Hemmer)
  8. Organization: InterActivsion
  9. Lines: 44
  10. X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith
  11.  
  12. In article <1992Aug27.045116.22134@jato.jpl.nasa.gov> jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
  13.  
  14. >     I was led to believe that the names of the files in a directory are
  15. > stored within the directory file itself. But if this is truely the case,
  16. > then why is a listing of that directory with the "QUICK" option hardly any
  17. > quicker than without? 
  18.  
  19. The QUICK option of List reduces the output to the file or directory names,
  20. not including size, data etc. as usual. The List program still goes through
  21. exactly the same amount of information, it only outputs less. So QUICK has
  22. nothing to do with the execution time.
  23.  
  24. A disk structure starts with the root block. From there every directory and
  25. file on a disk can be derived (through linkage). Directories and files are
  26. chained together through a hashing mechanism, which you can read about in
  27. the AmigaDOS 3rd Edition manual from Bantam Books (ISBN 0-553-35403-5).
  28.  
  29. >     I'd like to use the ExAll function, but I'm not savy on how large a
  30. > buffer to supply. Ideally, the buffer would only be as large as need be. So
  31. > for instance, if I were interested in only obtaining the names contained in
  32. > a directory would fib_Size reflect at least how large that buffer needed to
  33. > be?
  34.  
  35. fib_Size reflects the size of the file examined. It has nothing to do with the
  36. amount of buffer you need to hold for the entire directory. When you examine
  37. a directory you need to allocate `sizeof (struct FileInfoBlock)' for each file
  38. or directory encountered. If you're only interested in part of the information
  39. contained in the FileInfoBlock say the size of the file, one FileInfoBlock
  40. allocation will suffice. You can then copy the size values to your own size
  41. buffer, or just add them up (or whatever your purpose is :-). All information
  42. about the file or directory can then be found in the FileInfoBlock structure.
  43.  
  44. >     Any help much appreciated.
  45.  
  46. Hope this clarified a bit.
  47.  
  48. -- 
  49. *-------------------------------------------------------------------------*
  50. |         _   UseNet: (uunet|rutgers|pyramid)!cbmvax!cbmehq!cbmden!hemmer |
  51. |         \\ _                         CBMNET: hemmer@hemmer.adsp.sub.org |
  52. | InterActi\X/ision - The name of precision                               |
  53. | Best regards                         >> Carpe Diem! - Seize the day! << |
  54. | Franz Hemmer - Software Developer located in Silkeborg, Denmark, Europe |
  55. *-------------------------------------------------------------------------*
  56.