2

I have several audio devices (car radio, portable radio, MP3 player) that take SD cards and USB sticks with a FAT file system on it. Because these devices have limited intelligence they do not sort filenames on the FAT FS by name but merely play them in the order in which they have been copied to the SD card.

In MS DOS and MS Windows this was not a problem; using a simple utility that sorted files alphabetically and then copied them across in that order did the trick. However, on Linux the files copied from the ext4 file system do not end up on the FAT FS in the same order as in which they were read and copied across, presumably because there is a buffering mechanism in the way which improves efficiency but does not worry too much about the physical order in which the files end up on the target device.

I have also tried to use Windows in a Virtual Box VM but still the files end up being written in a different order than the one they were read from the Linux file system.

Is there a way (short of copying them across manually one by one and waiting for all write buffers to be flushed) to ensure that files end up on the FAT SD target in the order in which they were read from the ext4 file system?

4
  • this has nothing to do with Unix so it's off-topic here. Duplicates: Default file order of "dir" command in Windows console. There are lots of reordering tool(see the previous link), no need to copy out then re-copy even on Windows, just sort the FAT entries
    – phuclv
    Commented Dec 9, 2022 at 4:32
  • It's a question on how Unixen treat FAT/FAT32/VFAT file systems with respect to buffering and physical allocation. Your link on the Windows "dir" command is not relevant in that context. Commented Dec 20, 2022 at 9:19
  • the FS driver always read the next entry in the way that the filesystem stores the entries physically, so the read-out order is the same in any OSes
    – phuclv
    Commented Jan 5, 2023 at 2:03
  • 1
    This question is on-topic. There are additional answers on superuser.com, where I added a short script based on @anarcat's suggestion. Commented Apr 16, 2023 at 9:41

2 Answers 2

3

In my experience, moving the files into place in the right order (e.g. moving file A then file C then file B if you want the order "ACB") works as long as you do it all at once.

In other words, if you already have files and then add a bunch more, they might get injected anywhere in the order, which is probably not what you want.

So my trick, when I add files in a directory, is to first move all the files out, then re-add them all in the right order. I typically number all files with a numbered prefix so I can order the alphabetical order, then move them back all at once.

So it looks something like this:

mv 100newfileA 101newfileB folder/
cd folder
mkdir order
mv * order
mv order/* .

It's utterly bizarre and counter-intuitive, but it works in my case.

By the way, a sure way to list the files in the actual disk order (as opposed to alphabetical order), in Linux/UNIX systems, is with ls -U (or ls --sort=none).

1
  • something like following can make it recursive, started in /media/myself/MP3/Music/ with existing directory order: find . -type d -print0 | while IFS= read -r -d "" d; do cd "$d"; pwd; mv * /media/myself/MP3/Music/order; mv -v /media/myself/MP3/Music/order/* .; cd -; done
    – Jaleks
    Commented Nov 27, 2023 at 14:49
1

I remember asking this a long time ago (you are welcome to search for it). My guess at this long future time is: mount the device with option sync (removes the buffering), sort the list to ensure that they are copied in order.

2
  • Thanks, that looks like it should work. One caveat though: the 'mount' man page states that "In the case of media with a limited number of write cycles (e.g. some flash drives), sync may cause life-cycle shortening." No help for it, but good to keep in mind. Commented Feb 18, 2020 at 10:48
  • 1
    @FrankvanWensveen I imagine that this same warning would also apply to simply using windows or MS DOS. My experience is that they buffer much less with removable media, presumably because users don't remember to "eject" media before pulling it out. If what you say in your question is true then windows may be performing a "sync" operation for every file copy, where linux is not so presumptious. Commented Feb 18, 2020 at 11:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .