GNOME Bugzilla – Bug 709818
Nautilus' sorting is inconsistent with regards to filename extensions
Last modified: 2021-06-18 15:56:05 UTC
Created attachment 256906 [details] Screenshot of inconsistently-sorted filename list in Nautilus [Upstreaming my Fedora report from RHBZ#1017773] Description of problem: There's something weird about how Nautilus sorts same-named files with different extensions. When the filename changes, the order of sorting EXTENSIONS can reverse itself. Version-Release number of selected component (if applicable): nautilus-3.8.2-1.fc19.x86_64 How reproducible: Always? Steps to Reproduce: 1. Open folder containing appropriate set of files 2. Switch to List view 3. Sort list by Name Actual results: A list of files, sorted inconsistently. Expected results: Sanity. Additional info: To save you needing to look at the screenshot, consider the following directory of files, sensibly ordered in the output of 'ls -1': 003.part 003.part.met 003.part.met.bak 005.part 005.part.met 005.part.met.bak 006.part 006.part.met 006.part.met.bak 006.part.met.seeds 009.part 009.part.met 009.part.met.bak 010.part 010.part.met 010.part.met.bak In Nautilus, the attached screenshot shows that those same files are sorted ("by Name") thusly: 003.part.met.bak 003.part.met 003.part 005.part.met.bak 005.part.met 005.part 006.part.met.bak 006.part.met.seeds 006.part.met 006.part 009.part.met.bak 009.part.met 009.part 010.part 010.part.met 010.part.met.bak Even if you believe that the longest-extension-chain-first ordering is sensible (I disagree, but that's neither here nor there), note that the extension order REVERSES itself when the filename base changes from 009 to 010! Whatever kooky ordering Nautilus uses for filenames, it needs to at least apply it consistently.
Created attachment 374220 [details] demonstration code This looks like a bug in GLib. With the attached file, we can see that “06” names are converted to end with \2, whereas “10” name correctly ends with \1: > 006.part.met -> 6partmet > . . . . 6 . . . . p a r t . . . . m e t . > 01 01 01 02 36 01 01 01 01 70 61 72 74 01 01 01 01 6d 65 74 02 > > 006.part.met.bak -> 6partmetbak > . . . . 6 . . . . p a r t . . . . m e t . . . . b a k . > 01 01 01 02 36 01 01 01 01 70 61 72 74 01 01 01 01 6d 65 74 01 01 01 01 62 61 6b 02 > > 006.part.met.seeds -> 6partmetseeds > . . . . 6 . . . . p a r t . . . . m e t . . . . s e e d s . > 01 01 01 02 36 01 01 01 01 70 61 72 74 01 01 01 01 6d 65 74 01 01 01 01 73 65 65 64 73 02 > > > 010.part -> :10part > . . . . : 1 0 . . . . p a r t . > 01 01 01 02 3a 31 30 01 01 01 01 70 61 72 74 01 > > 010.part.met -> :10partmet > . . . . : 1 0 . . . . p a r t . . . . m e t . > 01 01 01 02 3a 31 30 01 01 01 01 70 61 72 74 01 01 01 01 6d 65 74 01 > > 010.part.met.bak -> :10partmetbak > . . . . : 1 0 . . . . p a r t . . . . m e t . . . . b a k . > 01 01 01 02 3a 31 30 01 01 01 01 70 61 72 74 01 01 01 01 6d 65 74 01 01 01 01 62 61 6b 01 I am not really sure where does the \2 come from as the code only adds it after a sentinel which is not the case here: https://gitlab.gnome.org/GNOME/glib/blob/16e632432eb07616dc90899ad5ffb22c35c469c9/glib/gunicollate.c#L607
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.