What order does the DIR command arrange files if no sort order is specified?

If you don't specify a sort order, then the DIR command lists the files in the order that the files are returned by the Find­First­File function.

Um, okay, but that just pushes the question to the next level: What order does Find­First­File return files?

The order in which Find­First­File returns files in unspecified. It is left to the file system driver to return the files in whatever order it finds most convenient.

Now we're digging into implementation details.

For example, the classic FAT file system simply returns the names in the order they appear on disk, and when a file is created, it is merely assigned the first available slot in the directory. Slots become available when files are deleted, and if no slots are available, then a new slot is created at the end.

Modern FAT (is that an oxymoron?) with long file names is more complicated because it needs to find a sequence of contiguous entries large enough to hold the name of the file.

There used to be (maybe there still are) some low-level disk management utilities that would go in and manually reorder your directory entries.

The NTFS file system internally maintains directory entries in a B-tree structure, which means that the most convenient way of enumerating the directory contents is in B-tree order, which if you cover one eye and promise not to focus too closely looks approximately alphabetical for US-English. (It's not very alphabetical for most other languages, and it falls apart once you add characters with diacritics or anything outside of the Latin alphabet, and that includes spaces and digits!)

The ISO 9660 file system (used by CD-ROMs) requires that directory entries be lexicographical sorted by ASCII code point. Pretty much everybody has abandoned the base ISO 9660 file system and uses one of its many extensions, such as Joliet or UDF, so you have that additional wrinkle to deal with.

If you are talking to a network file system, then the file system on the other end of the network cable could be anything at all, so who knows what its rules are (if it even has rules).

When people ask this question, it's usually in the context of a media-playing device which plays media from a CD-ROM or USB thumb drive in the raw native file order. But they don't ask this question right out; they ask some side question that they think will solve their problem, but they don't come out and say what their problem is.

So let's solve the problem in context: If the storage medium is a CD-ROM or an NTFS-formatted USB thumb drive, then the files will be enumerated in sort-of-alphabetical order, so you can give your files names like 000 First track.mp3, 001 Next track.mp3, and so on.

If the storage medium is a FAT-formatted USB thumb drive, then the files will be enumerated in a complex order based on the order in which files are created and deleted and the lengths of their names. But the easy way out is simply to remove all the files from a directory then move file files into the directory in the order you want them enumerated. That way, the first available slot is the one at the end of the directory, so the file entry gets appended.

Of course, none of this behavior is contractual. NTFS would be completely within its rights to, for example, return entries in reverse alphabetical order on odd-numbered days. Therefore, you shouldn't write a program that relies on any particular order of enumeration. (Or even that the order of enumeration is consistent between two runs!)

Comments (28)
  1. Joshua says:

    I have seen a directory where Dir appears to return in random order but look up of one file in one hundred thousand in the directory is fast.

  2. RaceProUK says:

    Are there any filesystems that use bogosort? :)

  3. Anon says:


    I'd rather see a FS that uses PanicSort


  4. moswald says:

    This begs the question, why aren't they just specifying the sort order to begin with?

  5. Azarien says:

    @moswald: What for? Only to make directory operations slower? And what sort order? If you need files displayed in any particular order, simply sort the results after enumerating files.

  6. waleri says:


    This would require to specify a codepage as well.

    Plus, you may want your files in one order, I might want mine in another – which one shall we specify?

  7. Brian_EE says:

    So if this was an actual question, then it seems reasonable to assume the customer was trying to do something in a batch file. If so, then @moswald raises a valid question.

    Otherwise in a program, just enumerate the files and sort them yourself by whatever method you need, and be done with it.

  8. Jefito says:

    @Brian EE: Users of the DIR command can sort the listing themselves, using the /O option.

  9. jader3rd says:

    I'm fairly confident at this point that some big pieces of software depend upon NTFS's behavior to return alphabetically-ish first file behavior, and so at this point Microsoft might as well make it contractual.

  10. Anon says:


    I'm fairly confident that anyone writing code that depends on this would manage to screw it up even if it WAS contractual.

  11. Brian_EE says:

    @Jefito – I think you simply repeated exactly what I said (by my referring back to @moswald's statement).

    And then I said "Otherwise…" presumably because in a C-language program you wouldn't shell to "dir" to get the directory listing… you would use the Windows API instead. That's when you implement whatever sort you want.

    Oh… and what if the customer needs a sort that can't be accomplished by /Oxxxx flags? Then you're back to a custom solution.

  12. Kai says:

    Reminds me of a fairly big customer who halted a fairly big database upgrade project because all their reports had their sorting completely messed up, and "the vendor refuses to supply a fix for this bug". Turns out they always depended on GROUP BY sorting its output because, hey, what other way could their be to group something than by sorting it first? Well…you don't need an O(n log n) operation to group. You can hash and as soon as the database engine had been upgraded to do so…BOOM! So, yes, I am sure there is probably software dependant on NTFS sorting details.

  13. Duke of New York says:

    It is pointless for filesystem designers to speculate what iteration order might be generally useful to applications, because they will inevitably be wrong. That can be known only to the application designers, who have their choice of sorting utilities.

  14. Myria says:

    I have to nitpick on one thing: UDF is not an extension to ISO 9660.  It's merely capable of coexisting with ISO 9660 on a single disk for backward compatibility.

    It'd be nice if there were modes of operating systems that were designed to break as many application assumptions as possible.  Such a mode would return a random file order from Find(First|Next)FileW.  Maybe such a feature would be nice for Application Verifier.

  15. Joshua says:

    Indeed, dave just provided a back-compat reason to not standardize it. Samba returns NTFS because large numbers of programs look for "NTFS" to say "Oh good I can set file permissions on this filesystem." The underlying filesystem on the other side probably doesn't provide BTrees (ext3 uses htrees).

  16. JM says:

    @Nico: I can top even that. I saw a query that was incorrect break one day when the database happened to choose a different order to process rows in, which just happened to include a row where the condition it was evaluating was out of range. It took me a while to figure out that the query was indeed incorrect and it wasn't any bug in the query processor — it relied on short-circuit evaluation, when that's just not a feature, as natural as that is to assume for your average programmer. The query happened to work the whole time just because it happened to not hit the offending row during evaluation. What caused it to break? Adding rows to the table, which triggered a new execution plan. Hooray for assumptions that come back to bite you in the rear when you least expect them.

  17. Timothy Byrd (ETAP) says:

    We used to have reports written to an Access file that assumed the order of items in the report was the order the rows were written to the table.

  18. JM says:

    And just to be clear in the above: the query had been running fine for years, the row the query broke on had been in the table for years, and none of the rows added were out of range either! The server just happened to pick that day to demonstrate that the query was always wrong to begin with.

  19. dave says:

    >I'm fairly confident at this point that some big pieces of software

    >depend upon NTFS's behavior to return alphabetically-ish first file

    >behavior, and so at this point Microsoft might as well make it contractual.

    Then, of course, there will be *more* programs that work correctly

    on NTFS but which fail over the network where the file system is

    unknown (though people with an SMB implementation tend to lie and

    say "NTFS" because you've got to say something, and saying "Acme

    Read-Sometimes File System" will confuse even more apps. I confess

    to having uttered that lie myself).

  20. cheong00 says:

    @waleri: Agreed. There is a reason that SQL collations exist.

  21. Nico says:


    It's not even always a big database software upgrade that can change the default result ordering.  We saw that happen and break a few things (why does it always seem like reporting groups make the worst assumptions about query results?).  The cause for us: rebuilding an index on a table.

    Whether filesystems or databases, it's an important point to drive home: There is *no* default sort order.  As far as your application should be concerned results are returned in a random order.

  22. xpclient says:

    Unfortunately, more consumer electronics devices support FAT32 than NTFS so just running that low level tool to make the sort order alphabetical on FAT32 drives fixes the issue.

  23. Lawrence says:

    @Myria: Sorry, but pointless. The kind of developers who would rely on an undocumented sort-order in the FindxxxFile functions do not overlap, at all, with developers that would run their app through Application Verifier.

  24. Azarien says:

    Isn't exFAT an example of "modern FAT"?

  25. Deduplicator says:

    @Myria: Did you ever check out the DeathStation9K for C? Nobody likes it…

    exFAT: That' not "modern FAT". A completely different system from FAT as we like/hate it.

  26. Franz says:

    Is it possible to get an ordering by versions (like Linux's 'ls -lv' command)?

    For example I have a folder with the following content











    But I want it listed in the following order











    Is something like this possible?

  27. Jan Ringoš says:

    Franz: Use CompareString with SORT_DIGITSASNUMBERS when sorting.

Comments are closed.

Skip to main content