I have this problem with audio on my car's usb reader not playing it the order as displayed.
Then I recall one thing about the original FAT system. Not verbatim, but as I recall:"When a file is deleted, the slot is left there with ~ as first character... when a file is added, it go find the first empty slot... DIR display the files in slot order skipping the deleted..." So, native FAT "file order" is creation and/or modification date time, oldest=first.
Recalling that info, now when I move things around on my FAT32 audio usb stick, I reformat the USB stick and copy it back in the order I want the play to play. This ensured the play order is same as native storage order and the old DOS/WinXP DIR display.
Sorting/accessing by latest vs oldest also has a worst problem at least for me. Different Microsoft system (Win7 explorer, Win7 dos box, Win XP explorer, WinXP dos box...) may showing you different date/time for the same file. The times you see by these method could differ by 2 seconds and or +1 hours. That shows search by date/time really depends on what system you use and what program that systems use.
Win7 file explorer's date/time would use FILEDATE (stored somewhere hidden) where as, win7's dos box DIR use FILEINFO data in NTFS. FAT data is converted at run time to FILEDATE or FILEINFO data. WinXP file explorer and WinXP dos box use FILEINFO data. Of course, DOS uses data in FAT.
When Win7 windows, Win7 dos box, WinXP windows, WinXP dos box, dos may all be showing different date/time for the same file, it shows how directory searching and sorting by date entirely depends on how your "reading system" wrote its search.
-----------------------------------------------------------------------------------------------------
Detail info on the different "display time" if you are interested, here is "diving deeper into that rabbit hole":
In Windows, one could be using _FindFirst and _FindNext (with their w or no w variant) which returns _FILEINFO. When file is FAT, FAT data is converted to _FILEINFO data during run time. DOS is FAT's time structure obtained directly from FAT. Other systems like an audio or picture player... who knows.
As far as I know, there are two places to store file date/time, and three formats:
- FAT way is 16 bit 2 seconds resolution, no understanding of time zone and no understanding of daylight savings.
- _FILEINFO is 32 bit 1 second resolution Unix time.
- FILEDATE is 64 bit 100ns resolution in a hidden file.
The way microsoft implemented FILEDATE, in their words, they "want it to be reversible when a time occur twice." A time occur twice on daylight savings time change and turn the clock back 1 hour. I don't know what they mean by reversible. Net result is, on Win7 (may be for later as well) where I tried to put in a "touch" function in a program, some unix time values cannot be used as FILEDATE during certain times.
You convert the unix time value into FILEDATE format, put it into FILEDATE say as last mod date, update the file's FILEDATE, read it back, convert it back to unix time, and the unix time value you read back may not be the unix time value you you started with. The read back value will depend on the time value's DST/EST status (ie: is the date you are setting a DST date or not), the DST/EST of when you did the setting, and the DST/EST of when you did the reading. Yeah, I am positive you don't always get back the same. You can offset that value by 3600 (1hr), you may read the right value back immediately, but then when you read it back again after DST/EST changed, you will get back a different time_t value. _tzset will not change that. However, if you turn off "automatic daylight saving time adjustment" for your machine, that problem will go away.