linuxmint / nemo

File browser for Cinnamon
GNU General Public License v2.0
1.21k stars 299 forks source link

Files not properly sorted by name #2135

Open JChristensen opened 5 years ago

JChristensen commented 5 years ago
* Nemo version: Nemo 4.0.6
* Is issue with desktop or windowed nemo? (Not sure what this question means!)
* System:
  Host: op745 Kernel: 4.15.0-48-generic x86_64 bits: 64 compiler: gcc 
  v: 7.3.0 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19.1 Tessa 
  base: Ubuntu 18.04 bionic 
* Graphics:
  Device-1: NVIDIA GT218 [GeForce 8400 GS Rev. 3] vendor: eVga.com. 
  driver: nvidia v: 340.107 bus ID: 01:00.0 
  Display: x11 server: X.Org 1.19.6 driver: nvidia 
  unloaded: fbdev,modesetting,nouveau,vesa resolution: 1600x1200~60Hz 
  OpenGL: renderer: GeForce 8400GS/PCIe/SSE2 v: 3.3.0 NVIDIA 340.107 
  direct render: Yes 

Issue Nemo does not sort files by name correctly.

Steps to reproduce Run script below to create a directory and some files. Start Nemo, navigate to folder created by script. Click on Name heading to sort by filename.

Expected behaviour Nemo sort order is the same as that of the ls command.

Other information Screen shots of Nemo and ls showing different sort order.

nemo

nemo-ls-l

Script

#!/bin/bash
# Demonstrate Nemo sorting issue.
# Script to create a directory containing a number of files.
# J.Christensen 13May2019

testDir="nemo-test"

# create a test directory.
# if it already exists, delete it and recreate it.
if [ -d "$testDir" ]; then
    echo "Remove directory: $testDir"
    rm -r $testDir
    echo "Create directory: $testDir"
    mkdir $testDir
else
    echo "Create directory: $testDir"
    mkdir $testDir
fi

touch "$testDir/032ad501ec3451538972d0889bccb1cc"
touch "$testDir/03b07cba1bd05911473224623ce2d042"
touch "$testDir/03f430780fdc5f6a0c6e8fa9c21412a0"
touch "$testDir/0b23484b33653d227d3bc6dc6af4ffc6"
touch "$testDir/0c87381acadb9df29fab5003abb67dc0"
touch "$testDir/15f5843b06a421e7034a7933dbd13844"
touch "$testDir/1aaecefa5e411728bec1d597ab4547e1"
touch "$testDir/1c59fb5ea9895fdee4ed34d45f6b234f"
touch "$testDir/1cd82066940d189dbfbabf2b74c8d29e"
touch "$testDir/1e64eb47bd5def9d3e8eb1ce38517bda"
touch "$testDir/1f46679e3e59efa3320767c1e3e37994"
touch "$testDir/28e0b8c245b22cf32b979823f0a24e5a"
touch "$testDir/2c1f579b86d33e182fd13da000f62068"
touch "$testDir/2e00588874f4cef4f8bdcc4ad3fb8175"
touch "$testDir/2f80481a73bf4c7cc57273c26588af15"
touch "$testDir/2f90af8db29d75f395cec40a9b35659c"
touch "$testDir/38f45472c75d70a5aa701a652ab80d15"
touch "$testDir/3b052823df0be600df611dfedab1d8ab"
touch "$testDir/3f493938c5c9bc4c7df660e98ee57a2b"
touch "$testDir/3f9c959615eb9752c2c352377d1027b3"
mtwebster commented 5 years ago

I tried half a dozen other file managers and they all exhibit this behavior. I started playing around with simpler filenames: Screenshot from 2019-05-13 18-05-26 I can definitely see some order here, it's just not what I would expect. There could very well be a good reason for it also, I haven't had a chance to dig any deeper yet.

Both nautilus and nemo use this function to generate keys to compare: https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-collate-key-for-filename.

Interestingly, if I use simple g_utf8_collate_key () instead of the filename version, the sort order seems how I would expect it to be: Screenshot from 2019-05-13 18-15-41 back to your original file list, it now becomes: Screenshot from 2019-05-13 18-15-56

I'll have to look at the source for those functions and see what's different. It seems there's more at work than the documentation implies. I may consider making this something configurable, as I'm pretty sure there are a few other bug reports of incorrect sorts.

Thanks

JChristensen commented 5 years ago

@mtwebster, thanks very much for the feedback and I'm glad you were able to reproduce the issue. I was working on a project that generated several hundred files whose names were md5 hashes. This is not particularly causing me any hardship but it seemed strange enough that I thought I would report it.

I did check other issues before raising this one and saw some with sorting issues but they all seemed to involve special characters (underlines, etc.), so this seemed at least somewhat different. With all my filenames being the same length and made up of normal alphanumeric characters, I thought it odd that a name that started with "2" sorted before one that started with "0".

Thanks again! We are really enjoying Linux Mint. You all are doing a super job. 19.1 is an excellent release. 18.3 was working so well for me that I thought I'd wait longer to upgrade, but 19.1 seems even better.

clefebvre commented 5 years ago

The 0 is ignored basically. It tries to identify the relevant number. For instance, in 028e, it's neither 0, nor 2 which is relevant, it's 28.

I think the main idea is to order things the way people would expect, neither alphabetically nor numerically, but logically, with 10 being higher than 9 and with 90 being higher than 10.

JChristensen commented 5 years ago

I see what's going on now. It's probably working as designed. Any string of digits (0-9) is replaced by its value for sorting purposes. https://en.wikipedia.org/wiki/Natural_sort_order

I suppose this is desirable in some or even many situations. In my case with filenames that are hexadecimal values, the results seemed nonsensical.

Personally I'd almost always want just a simple straight alphabetical order like ls, so I'd definitely welcome an option in Nemo's preferences to choose the desired sorting algorithm.