Den 28/08/2013 kl. 12.00 skrev [email protected]:
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 _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
