Name sorting is wrong

Marco van Hulten said:

I experience the same problem in Thunar 1.6.6:

but the listing in Thunar is thus:

2003
19980102
20030102

I use ISO 8601 dates, but maybe that's a moot point. The main problem is that this is not what I expect. I cannot find anything about sorting in thunar(1) or the online manual (except for sc-case-sensitive).

Marco van Hulten said:

Massimo, you wrote '$(ls -l)' twice. What do you mean?

Furthermore, I found out that all the file managers I tried, pcmanfm, caya, vifm and ranger, have the same behaviour as thunar.

Is there a common library used that implements a sorting algorithm?

Is there some sort of standard for sorting?

Andre Miranda @andreldm said:

Sorting is determined by LC_COLLATE[1], try: thunar -q LC_COLLATE=c thunar

Let me know if that helps.

https://wiki.archlinux.org/index.php/locale#LC_COLLATE:_collation

Massimo Burcheri said:

Hi all, thanks for your interest in a 4 years old bug. Playing around with the ls options I was able to reproduce the Thunar sorting with "-v natural sort of (version) numbers within text". What I meant in 2014 is this:

My expected sorting: $ ls -1 20100321_foo 20120114_foo 201205_foo 2012_foo 201312_foo

How Thunar does the sorting: $ ls -1v 2012_foo 201205_foo 201312_foo 20100321_foo 20120114_foo

No, LC_COLLATE=c did not solve it. Are you able to reproduce the sorting?

Andre Miranda @andreldm said:

Indeed, LC_COLLATE=C (uppercase C, sorry for my typo) did not help, I remember it was useful for other sort issues, but in this case.

Searching about this, I found that users are not happy with Thunar in this sense: https://unix.stackexchange.com/questions/10581/is-it-possible-to-make-thunar-sort-by-ascii-order https://forums.linuxmint.com/viewtopic.php?t=213844

Taking a look at the source, it seems the revelent function is thunar_file_compare_by_name. It uses ThunarFile's collate_key and collate_key_nocase, both generated by g_utf8_collate_key_for_filename. The odd thing about it is that ":" is prepended to filenames: :::2012_foo :::::201312_foo :::::201205_foo :::::::20120114_foo :::::::20100321_foo

Quoting g_utf8_collate_key_for_filename source comments:

Numbers are handled by prepending to each number d-1 superdigits where d = number of digits in the number and SUPERDIGIT is a character with an integer value higher than any digit (for instance ':'). This ensures that single-digit numbers are sorted before double-digit numbers which in turn are sorted separately from triple-digit numbers, etc. To avoid strange side-effects when sorting strings that already contain SUPERDIGITs, a '\2' is also prepended, (...)

This has the side-effect of sorting numbers before everything else (except dots), but this is probably OK.

That function usage was introduced by Bug #7110. Needs further investigation...

Theo Linkspfeifer closed a related bug:

*** Bug 11075 has been marked as a duplicate of this bug. ***

Maybe this is a related problem: If two files containing ____ at the beginning are sorted to totally different locations: see original image here

____arcj0.jpeg
___arcj07.jpeg
___arcj09.jpeg
__arcj12.jpeg
arcj01.jpeg
arcj02.jpeg
____Schriftzug.txt

The last file should be on top with the rest

It's interesting to notice that Nautilus and Nemo sorts file exactly like Thunar.

If you use LC_COLLATE=C you will get your expected results.

added 5. File Arrangement label

I suppose duplicate of #1015 (closed) (Whereas the bug actually is this upstream bug: https://gitlab.gnome.org/GNOME/glib/-/issues/1344)

That would as well explain why it is bugged for Thunar, Nemo and Nautilus --> Sufficient indication for me to close this bug :) (feel free to reopen if I should be wrong)

closed

added 3. Not Xfce label

mentioned in issue #1015 (closed)

mentioned in issue #1340

Name sorting is wrong

Submitted by Massimo Burcheri

Description

Designs

Child items ...

Activity