I have the following directory setup that I include in my mkefs build file with “foo=/xxx/foo” (so it includes the 
folder and all subfolders/files):

+---foo
|   \---bar
|       +---subbar1
|       \---subbar2

From my windows cmd shell, “dir /B foo\bar” returns:
subbar1
subbar2


However, if I move the foo directory (same contents) to one of our drive-mapped share servers (I think it’s a linux 
server running a samba share, but I’m really not sure... it’s IT controlled), this server returns the following in 
response to “dir /B foo\bar”:
subbar2
subbar1

(Same results, but in a different order.)

I also wrote a sample msys/mingw program that uses readdir() – and the results come out in the same order as the 
Windows “dir /B” command (different depending on whether the foo directory is on the server or my local PC).

mkefs (run with –nn to strip timestamps) creates different binaries, depending on whether I’m using the foo directory 
from my local drive vs. foo from the server. Based on the verbose output (and from looking at the mkxfs source), it’s 
adding the subdirectories in the order returned by readdir() -- so while the files in the EFS image are the same, the 
EFS image itself is different. This is problematic for us since we CRC the entire EFS image (and the identical input 
files are creating a different CRC’d image).

My understanding is that readdir() does not guarantee a file ordering -- it is up to the OS to return file entries in 
whatever order it sees fit (which is why utilities such as “ls” do a sort on returned items before displaying them). I
’d like to see mkifs/mkefs also do a sort when including entire directories so that the output is identical as long as 
the input files are identical, regardless of the order returned by readdir(). (I still prefer that files be added to the
 EFS in the order specified in the .build file, as they are today -- only sort when entire directories/subdirectories 
are added).