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