Bug 253817

Summary: The -v option of ls does not handle /boot version numbers properly
Product: Red Hat Enterprise Linux 5 Reporter: arch harris <service>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5.0CC: kdudka, msusta, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:17:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch for rawhide coretuils none

Description arch harris 2007-08-22 04:57:38 UTC 
Description of problem:

The -v option of ls should sort files by version umber but it does not work
properly when handling version numbers like those used in /boot/vmlinuz* files.
For example, of vmlinuz-2.6.18-8.1.8.el5 and vmlinuz-2.6.18-8.el5, `ls -v'
imporpoerly lists vmlinuz-2.6.18-8.el5 as the more recent.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. ls -v /boot/vm
2.
3.
  
Actual results:
vmlinuz-2.6.9-5.0.3.EL
vmlinuz-2.6.9-5.0.5.EL
vmlinuz-2.6.9-5.EL
vmlinuz-2.6.9-11.EL
vmlinuz-2.6.9-22.0.1.EL
vmlinuz-2.6.9-22.0.2.EL
vmlinuz-2.6.9-22.EL
vmlinuz-2.6.9-34.0.1.EL
vmlinuz-2.6.9-34.EL
vmlinuz-2.6.9-42.0.2.EL
vmlinuz-2.6.9-42.0.3.EL
vmlinuz-2.6.9-42.0.8.EL
vmlinuz-2.6.9-42.0.10.EL
vmlinuz-2.6.9-55.0.2.EL
vmlinuz-2.6.9-55.EL



Expected results:
vmlinuz-2.6.9-5.EL
vmlinuz-2.6.9-5.0.3.EL
vmlinuz-2.6.9-5.0.5.EL
vmlinuz-2.6.9-11.EL
vmlinuz-2.6.9-22.EL
vmlinuz-2.6.9-22.0.1.EL
vmlinuz-2.6.9-22.0.2.EL
vmlinuz-2.6.9-34.EL
vmlinuz-2.6.9-34.0.1.EL
vmlinuz-2.6.9-42.0.2.EL
vmlinuz-2.6.9-42.0.3.EL
vmlinuz-2.6.9-42.0.8.EL
vmlinuz-2.6.9-42.0.10.EL
vmlinuz-2.6.9-55.EL
vmlinuz-2.6.9-55.0.2.EL




Additional info:
Comment 1 Ondrej Vasik 2007-12-03 11:39:02 UTC 
Thanks for report. ls is using strverscmp function for -v option. There was
already one similar bug filled against that function in glibc (
http://sourceware.org/bugzilla/show_bug.cgi?id=3506 ) and was closed that this
is required behaviour. Coreutils have in lib subdir its own strverscmp.c file,
so maybe that could be changed for coreutils to correct version displaying. But
now is the glibc function used (at least in coreutils I have checked) - and this
one will not change. Will try to find something more about the possible solution
- because current behaviour is wrong for RHEL/Fedora versioned files with dist tag.
Comment 2 Kamil Dudka 2008-09-04 08:53:48 UTC 
Created attachment 315725 [details]
patch for rawhide coretuils

Possible solutions of this issue were proposed upstream by Ondrej Vasik, you can watch the thread at http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00027.html

I am not sure if change of known ls behavior is acceptable by coreutils upstream. But there is new option --version-sort (-V) in sort utility, which has not been released yet. So if it will be accepted at least for sort, you can use then 'ls | sort -V' instead.

Anyway I am attaching a patch for rawhide coreutils, which gives expected results.
Comment 3 Kamil Dudka 2008-10-06 13:56:59 UTC 
New version compare algorithm will be presented in upcoming coreutils v7.0 - function filevercmp: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e505736f8211a608b00dfe75fb186a5211e1a183

The filevercmp function is designed as strverscmp replacement and is used in ls -v and sort -V as sort predicate.
Comment 5 Kamil Dudka 2009-03-05 22:10:27 UTC 
Slightly improved filevercmp behavior while comparing hidden files:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0443c2f39943017f0aaa0afacbf68fb725858963
Comment 10 errata-xmlrpc 2009-09-02 09:17:29 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1262.html