home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / programm / 13388 < prev    next >
Encoding:
Text File  |  1992-09-15  |  1.5 KB  |  32 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!stanford.edu!ames!elroy.jpl.nasa.gov!jato!jdickson
  3. From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
  4. Subject: Re: Determining file length
  5. Message-ID: <1992Sep15.155109.13858@jato.jpl.nasa.gov>
  6. Organization: Jet Propulsion Laboratory
  7. References: <mbs.108r@adastra.cvl.va.us>
  8. Date: Tue, 15 Sep 1992 15:51:09 GMT
  9. Lines: 21
  10.  
  11. In article <mbs.108r@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
  12. >In article <1992Sep14.152206.28572@cs.uow.edu.au> u9147063@cs.uow.edu.au (Richard Barry Ling) writes:
  13. >> Is there a better way to find file length in assembly language than to do a
  14. >> Lock() on the file, allocate a half-k buffer or so for the crap Examine()
  15. >> returns (I only want one long word of it :-(... ) pass that to Examine,
  16. >> extract the file length, free the Examine() buffer, unlock the file... it's
  17. >> screenfulls of code and an utter kludge. Can the file length be found in the
  18. >> file structure you get from Open() or something?
  19.  
  20. Allocate a temporary FIB on the stack, convert it to a BPTR, examine the
  21. object, extract the size of the file, and finally deallocate the FIB. Now, the
  22. C= folks tried to scare us all into using AllocDosObject for such purposes,
  23. but for now anyways it's a farce. The only requirement is that the FIB be long
  24. word alligned. 
  25.  
  26. You wanted to avoid having to lock the object, but if you're planning to open
  27. it anyways might as well use the new function to convert a lock into a file
  28. handle. 
  29.  
  30. jeff
  31.  
  32.