Order of files returned by readdir

[jpfarmer]

I have an application where I use readdir to iterate over the files in a directory handle opened by opendir. Perldoc gives the following explanation of how the function works:

Returns the next directory entry for a directory opened by "opendir".

However, it does not specify how "next" is determined. From my own quick testing, it appears that the order is consistent, but I have not been able to discern how the order is derived and it does not appear to be documented anywhere.

Do any of you know how the order is determined?

[Fletch]

However your OS' underlying readdir() routine returns them. My copy of Stevens (APUE, p108) says that the ordering is implementation dependent and usually not alphabetical. Safest thing to do if you want a particular ordering is to sort the results yourself after the fact.

[GrandFather]

Actually the order won't even be consistent. For example, deleting an entry then adding another will likely change the order somewhat. The order depends on the operating system and the file system that is being used.

With Windows for example, readdir most likely uses FindFirstFile/FindNextFile which don't specify the order files are returned.

[Argel]

Perl's readdir is for the most part a frontend/wrapper for an OS system call (readdir on UNIX) so don't expect sugar-coated responses. On Solaris (and probably other UNIX varients) you will get '.' and '..' back as well. If I was going to assume anything it would be that it returns the contents of the directory in the order they were created in (i.e. like a queue). But as previosuly mentioned, sort it yourself if you need a specific order.

[helgi]

On Solaris (and probably other UNIX varients) you will get '.' and '..' back as well.

On Windows as well.

[superfrink]

The entries are probably returned in whatever order the implementor figured would be the fasted order to return them.

Traditionally Unix filesystems store a list files and directories in an unsorted list. Think of it as an array. The fasted way to return the items is to just loop over the array.

A fast way to insert an item into the array is to insert in the next unused slot. Suppose the filesystem does not keep an index that points to the next free slot so the system just loops over the array until it finds a free slot.

A fast way to remove an item is to loop over the array to find the item and then just mark that slot as unused. The system could sort the array when an item is removed but that takes time so it likely just leaves an open slot wherever an item is removed.

There are filesystems (like ReiserFS) that use trees for indexing to give faster searching. In the end the order that items are returned by readdir is not defined to be sorted in any particular way so it's up to the application to sort the items as required.

[Jim_Gillespie]

Personally I view this as a feature - at work I deal with directories containing thousands of files, and often I want to just count them or do something else which is order-independent. So rather than use ls, which always sorts its output somehow, I've written a tiny perl script which just returns the list of files as given by readdir().

[Anonymous Monk]

man ls ... -f do not sort, enable -aU, disable -lst

[leocharre]

You need to sort them. If you feed them into an array..

use strict;

my @f = qw(leo and magalena went down to the basement to get some good
+ scotch they had hidden from their uncle);

@f = sort {$a cmp $b} @f;

for (@f){ print "$_\n";}

This will sort alphabetically. You could also have done a stat on these files and fed all into a hash, then you compare the key values.

Do a search right here on perlmonks for "directory listing" and you may find all kinds of goodies.

If this is *not* going to be a cgi, then yes you can do a call to the system by this for example:

my @sorted_files = split(/\n/, `ls /home/myself/ -S -r`);

This lists everything in my homedir by size in reverse, so... smallest files first. of course, this is no longer perl. Don't get used to backticks if you plan on doing serious webstuff.