Obtaining the size of a file

John Craig jc at spl21.net
Sun Apr 22 15:11:54 EDT 2007


It's an app where files and folders are selected as part of a backup 
process.  Folders can be selected, in which case the entire folder 
contents would be used.  In the case of individual files (or just a few) 
selected in any given folder, only info for those specific files are 
required.  The app should be capable of running on a basic (possibly 
ancient) machine, so any speed improvements are a bonus.

I appreciate all the responses - they are helpful and useful, but you 
seem a bit over protective of rev for some bizarre reason - I can't 
think why anyone would argue against having a concise one line function 
call for something this basic.

Looking at how this thread turned out from a question where the answer 
appears to be 'No' now makes me think that the detailed files isn't so 
long winded after all  :-)

This link may help you to relax a bit ;-)

http://www.emanator.demon.co.uk/bigclive/tickle.htm

Have fun,

JC

Richard Gaskin wrote:
> John Craig wrote:
>> Maybe I should have said 'another lengthy function call per line'...
>> I already use a cached file list, but if I hit a folder with 
>> thousands of files in it and only need the size of 1 file in that 
>> particular folder, it seems like wasted CPU time to pull the entire 
>> folder contents.
>
> Maybe, and maybe not.  I thought I'd read a recent post from you where 
> you'd said you needed this info for thousands of files across multiple 
> directories, no?
>
> If so, while the overhead of the function call is modest for a single 
> file (and might be made faster with your Bugzilla request for a 
> one-liner -- what's that BZ #?), if you need to do this for every file 
> in a directory then obtaining all of that info in one call would seem 
> rather ideal, yes?
>
> Can you tell us a bit more about this circumstance in which you need 
> to obtain this information for thousands of file in a directory, but 
> not all at once, and in a context in which the roughly quarter of a 
> millisecond even my long version takes would be prohibitive?
>





More information about the use-livecode mailing list