Parsing order in a folder

[tototrix23]

Hi everyone,

It's not an issue but a question. When you create hundred of files in a folder and you want to parse it:
what is the parsing order ? The oldest created file to the newest ? Is it true all the time ?

Best regards.

[geky]

Hi @tototrix23, thanks for creating an issue.

The order lfs_dir_read returns files is a bit weird. It's almost alphabetical, but with larger file names being returned first.

Originally the ordering was intended to be strictly alphabetical, but a bug in the comparison logic went unnoticed. Backwards compatible with existing disks makes this difficult to change without a minor/major on-disk version bump. More info here: #923.

Still, this ordering can be useful if you want to intentionally order files with same-sized filenames.

[cryptoAlgorithm]

Hi @geky

Could I clarify if the larger file names being returned first only applies to names which would otherwise be equal, save for their length? If my understanding of the bug is accurate, sorting order of names of different lengths is correct except when they only differ in length.

i.e.
1234 < 234 (correct sorting)
11111 > 111 (incorrect, longer string first)

Is my understanding correct?

[geky]

Could I clarify if the larger file names being returned first only applies to names which would otherwise be equal, save for their length?

@cryptoAlgorithm, yes! Can confirm this is how it works.

The problem line is:

littlefs/lfs.c

Lines 1468 to 1471 in adad0fb

	// only equal if our size is still the same
	if (name->size != lfs_tag_size(tag)) {
	return (name->size < lfs_tag_size(tag)) ? LFS_CMP_LT : LFS_CMP_GT;
	}

Before that we compare:

littlefs/lfs.c

Line 1460 in adad0fb

lfs_size_t diff = lfs_min(name->size, lfs_tag_size(tag));

---

It's also worth mentioning this is being fixed in littlefs3 (#1111, unstable), this time with tests!

• test_dirs_ordering
• test_dirs_ordering_length

[cryptoAlgorithm]

@geky, thanks for the follow up! Good to hear my understanding is accurate - it shouldn’t cause significant issues in our application.

Noted that it’s been fixed in the next major release! However the nature of the application means it’s not possible to update it post deployment, but it’s good to know it wouldn’t occur again.