Strange behavior of files()

[Michael Kristensen]

Den 28/08/2013 kl. 12.00 skrev use-livecode-request at lists.runrev.com:


Richard, you were right in both cases.

A sort put it straight and the number of files was correct.

So no bug, but can cause hair-pulling in some cases.

Thanks for your swift reply.


It vas while I used Chipp Walters altThumbViewer control - Beta 0.9 I noticed the anormality.

Michael




> Michael Kristensen wrote:
> 
>> I have a folder with 1347 jpg files
>> 
>> they are sequently named
>> 
>> xxxxxxxx 0001.JPG
>> xxxxxxxx 0002.JPG
>> xxxxxxxx 0003.JPG
>> ...
>> xxxxxxxx 1345.JPG
>> xxxxxxxx 1346.JPG
>> xxxxxxxx 1347.JPG
>> 
>> Strangely the files() function return a list omitting the first two and the last two.
>> 
>> Thus the list start with xxxxxxxx 0003.JPG and ends with xxxxxxxx 1345.JPG.
>> 
>> Anyone seen this behavior?
> 
> I've seen what *looks* like that behavior, until I double-checked and 
> discovered that file name listings returned from "the files" are not 
> always sorted.
> 
> Instead, they return the values as known by the OS, which for some file 
> systems often use inode order which may not reflect name sort order. 
> Directories with large numbers of files may be especially prone to this, 
> since the file lists are likely spread out across multiple inodes.
> 
> Try running the resulting list through the sort command to see if 
> perhaps the files you're looking for are actually there but had not been 
> where you'd expected them.
> 
> And an extra check might be to see if the number of lines in that list 
> matches what you see in the OS file manager.
> 
> If you find they're not there please post back so we can find the recipe 
> to pin down what at that point would be a bug.
> 
> --
>  Richard Gaskin