Filenames with leading zeros sort incorrectly in grid view

There are different ways to sort numeric data. At my work, we use product part numbers as filenames and many have a leading zero. Excel, Windows Explorer, Mac Finder, Bridge, and Lightroom all sort these a bit differently (Excel actually lets you sort numbers as numbers or text.)

I'm not sure there is a standard for how to sort these filenames.

Your logic is true if sorted as number. But it's not true is sorted as text (which it's most often the case for file names)

Filename is a text field, not numeric. For the sake of brevity I omitted the rest of the filename. 

Consequently the field should be sorted as a text field which would place 00 before 01

Here is a longer example, with some of the non-numeric parts deliberately repeated

For example, files where the first digits are:
0023 - File F
01  - File G
02 - File Z
023 - File G
024 - File K
03 - File W

should appear in the order shown above. Lightroom classic in grid view lists them as

01 - File G
02 - File Z
0023 - File F
023 - File G
024 - File K
03 - File W

Which is not correct.

I put this second set, the LR sequence into Excel, as text fields, sorted ascending and they get reordered into the first, i.e. correct sequence. 

There is no "correct" way to sort filenames. And Excel can sort numerical values as text or numbers. It pops up a dialog asking if you sort a column that is formatted as text but contains numerical values.

Like many other SW tools,  The distinction between treating numbers as alphanumeric characters (e.g. "0" is just the next letter after "Z") or treating them as numerical "values" has been blurred over the years.  In the old days of computing, a data field was either alphanumeric or numeric period.  If the field was numeric and you put in "123x" the computer would crash. 

Where this  first changed is in the treatment of dates.   If I have two dates.   1/2/2010 and 10/2/2010  which should come first?  If treated as an alphanumeric character, a "/" sorts after a "0" as I recall so October would come before January in the YMD system.  However if the SW treats them as "dates", then they sort into calendar order. 

So, over time (and due to numerous complaints like why is October before January) most SW has put in logic to treat such fields as hybrid data.  In other words, portions of the data that look like numbers or dates are treated as such.  So  "ABC002" would be treated as an Alpho portion followed by a numeric portions and "ABC002" would sort  after "ABC1"  (as the "002" and "1" are treated as numeric values not alphanumeric values).  In many cases the SW will do this only when it finds such numeric data anywhere in the field but other SW only does it if the numeric values are at the beginning or end of the filed or surrounded by "break" charachters such as spaces or hyphens or underscores.   Unfortunately there is no standard as it all depends on context and the whims of the developers.

So,  the way LR sorts file names in your example is not INCORRECT.  It may not be the way you desire, but it is correct in that it is putting files in order numerically based on the first part of the data (the string of digits) and then is using the non numeric part as a secondary sort  so that File F comes before File G as they are both numerically 23.

IMHO if Adobe changed this to pure Alphanumeric sorting, I would understand it and be OK with it but I suspect a large majority of LR users would be quite perturbed and would complain in large numbers.

Incorrect use of leading zeros. Use a consistent number of zeros. Foe example


0001

0002

0003


not


01

0002

003

Basically 003 does not equal 0003

Afraid that in LR, sometimes 003 does equal 0003 and/or might equal 004, or 005, ...

LR has a bug that was first reported 8 years ago by someone else, reproduced by others, including me and still hasn't been fixed.

That is, when you publish a file, LR contains code to avoid filename clashes in the target and will append "-<number>" when it thinks there will be a clash. That bit of code generally believes that 003 does not equal 0003. But not always! And more often it discards the numeric part completely, so 003 can be the same as 004 and/or 005 and/or 006

So lets say you start with files where what follows the number is the same;
003 - FileA.nef
0003 - FileA.nef
and publish jpg's

Generally the LR code will say 003 is not 0003 and create
003 - FileA.jpg
0003 - FileA.jpg
but sometimes it evaluates 003 and 0003 as identical and produces
003 - FileA.jpg
0003 - FileA-2.jpg
Its not predictable which of the two the outcome will be.

That is, if you run it again you may well get a different outcome, or the same as before. So, checking and renaming the output to remove he spurious -2 just creates a different problem down the line should you need to republish.

Or you might start with
005 - FileB.nef
006 - FileB.nef
and end up with
005 - FileB.jpg
006 - FileB-2.jpg;
so in this case 005 has been evaluated by LR to be the same as 006

Now there are ways to reduce the probability of this happening, which is when I noticed that in grid view 023 and 0023 are the same, yet may or may not be identical be in publish.

Would be easier if I had control over all of the FIleA bits in the above examples but I don't, plus there are about 45,000 older images with three digits and 6,000 more recent with four

Just have to live with this "feature" as given the number and sources of the images to make it consistently four digits isn't feasible and still wouldn't solve the issue with publish.

I observe a different ordering in LR grid view: 01, 02, 03, 0023, 023, 024. This is the same ordering used by Mac Finder and Windows File Explorer and is intentional -- see this post for a precise definition.  Since LR is operating as designed, I've changed this topic to a feature request.