I am using the standard FindFirst and FindNext to retrieve all files in a directory but I need the results to come back sorted ( in the same order that clicking on the name column in explorer would sort them basically ) How can I achive this This has to be done via Win32 Thanks
You need to read all the file names into some suitable collection and then sort them yourself. The Windows API doesn't provide any sorting facilities.
You can use the Indexing Service for this, but I would recommend just to handle the sorting yourself while using FindFirstFile.
Sorting is not possible with the FindFirstFile Win32 API. There is a slightly more advanced FindFirstFileEx, but even that does not allow sorting.
There is a Raymond Chen post on The Old New Thing about FindFirstFile's limitations.
Your best bet is probably to load all results into a vector, and then sort that.
Win32
First, use findfirst and findnext to find all the files (remember, findfirst and findnext support glob'ing (*.exe, etc)... Load the matching files into a list and sort it. The STL will help you there.
Linux
Use opendir() and readdir() to find all the files in a directory. Use fnmatch() on those files to do your glob'ing. And just like Windows, load the matching files into a list and sort it.
As everyone has pointed out, FindFirstFile()
does not and can not sort the files it returns. It operates at a fairly low level, and returns files in an order that relates to file system's natural order of directory entries in a directory.
On a disk formatted with FAT and FAT32, that order will strongly relate to the order in which the files were created, modified by file deletions and possible re-use of now empty directory entry slots. This is because FAT directories are (as on many unix filesystems) simply a packed array of fixed-size directory entry structs, along with an ugly hack to fit long file names written in Unicode into a directory structure designed for 8.3 names written in ASCII. Unlike Unix, Win32 API calls are required to read the directory entries, but that doesn't affect the order in which the entries are read.
On NTFS (as I understand it) directories are represented in some variant of a B-Tree and the natural order of files seen by the Win32 API is therefore related to the indexing natural to that data structure.
You can see the differences with the DIR
command at the command prompt. On a FAT32 volume, DIR
shows the files in a different order than it will if that same folder is copied to an NTFS volume. DIR /ON
should list files in the same order regardless of the underlying file system in use.
Neither unsorted order produced by DIR is the same as the order produced by Windows Explorer when you sort by Name. (For that matter, DIR /ON
isn't the same, either.)
Windows Explorer uses a case-independent sort, that also seems to ignore some punctuation marks in the sort, and tries to be clever about numbers. In particular, a simple use of qsort()
with stricmp()
won't get the same answer as Explorer. It isn't clear if the actual sort order used by either Explorer or DIR is documented anywhere.
For example, the following names sort like this in DIR:
C:\temp\test> dir/on/b
aoli.txt
a-one.txt
atwo.txt
b1.txt
b10.txt
b2.txt
b-20.txt
b21.txt
b3.txt
b-4.txt
but transcribing from Explorer sorted in the Name column they are in this order:
aoli.txt
a-one.txt
atwo.txt
b1.txt
b2.txt
b3.txt
b10.txt
b21.txt
b-4.txt
b-20.txt
I'm having trouble imagining the simple to apply in a comparison function to get the latter effect.