bugfindutils - Bugs: bug #20310, updatedb generates an invalid...

 
 

bug #20310: updatedb generates an invalid database of (1) one filename (=concatenation of all filenames on the fs)

Submitted by:  David Purdy <davy_gravy>
Submitted on:  Sun 01 Jul 2007 02:21:34 PM UTC  
 
Category:  updatedb Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  David Purdy Open/Closed:  Closed
Release:  4.2.31 Fixed Release:  4.3.9

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 03 Jul 2007 10:48:15 PM UTC, comment #7: 

While you are welcome to apply and/or distribute copies of the patch, you might prefer to wait for the next release of findutils 4.2.x or 4.3.x which should also include that change.

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 02 Jul 2007 05:32:23 AM UTC, comment #6: 

jay, the patch worked well.

Thank You Very Much!  :^)

updatedb and locate now work as they should!

I will pass the patch (& the configure file) along to the project leader.

w/ gratitude,

Dave

David Purdy <davy_gravy>
Sun 01 Jul 2007 10:08:58 PM UTC, comment #5: 

Thank you, jay:

most coreutils (including sort) are provided through busybox-1.5.1

1.  from  /usr/bin/sort  I have the following code snippet:

...
    if true
    then
        sort="/usr/bin/sort -z"
        print_option="-print0"
        frcode_options="$frcode_options -0"
    else
        sort="/usr/bin/sort"
        print_option="-print"
    fi
...

2.  As for sort, the -d and -r options work, but the -z seems not to (if I have interpreted you the command correctly).

"testfile" contains the following text:
box
124
zebra
candy
84lumber
lumberjack

results of sort commands:
-----------------------------
$ sort -d testfile   

124
84lumber
box
candy
lumberjack
zebra

-----------------------------
$ sort -d -r testfile
zebra
lumberjack
candy
box
84lumber
124

-----------------------------
$ sort -d -r -z testfile
box
124
zebra
candy
84lumber
lumberjack

=============

I am in the midst of a bootstrap-image build right now, but when done I will try the patch.  I do have m4 and autoconf installed.

thanks again

Dave

David Purdy <davy_gravy>
Sun 01 Jul 2007 03:14:58 PM UTC, comment #4: 

Just in case you don't have m4 and autoconf installed, the patch would generate the attached configure file.  It's best to test with the updated m4 file if possible, though, please.

(file #13217)

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 01 Jul 2007 03:11:39 PM UTC, comment #3: 

Please try the attached patch.

(file #13216)

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 01 Jul 2007 02:45:19 PM UTC, comment #2: 

My initial guess would be that you are using a findutils installation in whcih the "configure" script thought that sort had a working -z option, but in fact it doesn't work.

In updatedb.sh there is the following:

    if @SORT_SUPPORTS_Z@
    then
        sort="@SORT@ -z"
        print_option="-print0"
        frcode_options="$frcode_options -0"
    else
        sort="@SORT@"
        print_option="-print"
    fi

If my hypothesis is correct, this expands to ...
    if true
    then
        sort="sort -z"
        print_option="-print0"
        frcode_options="$frcode_options -0"
    else
        sort="sort"
        print_option="-print"
    fi

... but sort's -z option does not provide for sorting NUL-terminated strings.    Could you check both of these gueses please?

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 01 Jul 2007 02:25:08 PM UTC, comment #1: 

A clarification:

locate <any-filename-present-on-filesystem>

spews the single very-long filename....

locate <any-nonpresent-filename>

correctly returns nothing...

David Purdy <davy_gravy>
Sun 01 Jul 2007 02:21:34 PM UTC, original submission:  

At first I thought '''locate''' was broken...
 locate bob
spews a single, very long filename(=concatenation of all filenames present on the scanned filesystem).

locate -S seems to show the problem:

 locate -S
 Database /var/locatedb is in the LOCATE02 format.
 Locate database size: 2037547 bytes
 Filenames: 1 with a cumulative length of 2037535 bytes
         of which 1 contain whitespace,
         1 contain newline characters,
         and 1 contain characters with the high bit set.
 Compression ratio -0.00%

I have noticed that, on the other hand, '''updatedb --old-format''' does generate a valid database.  Using '''locate''' after the old-format updatedb does return valid results.

The compilation was done on in the OpenEmbedded/Bitbake environment, target platform is a PPC603 NAS device.

I have tried 4.2.29 and 4.2.31 - both exhibit the same problem. 

David Purdy <davy_gravy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #13217:  configure.bz2 added by jay (90KiB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by davy_gravy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-11-11 jay Open/ClosedOpen => Closed
        Fixed ReleaseNone => 4.3.9
    2007-07-03 jay StatusNone => Fixed
        ReleaseNone => 4.2.31
    2007-07-01 jay Attached File- => Added configure.bz2, #13217
    2007-07-01 jay Attached File- => Added 0008-Fix-Savannah-bug-20310-sort-z-works-on-host-but-n.patch, #13216
    2007-07-01 jay Assigned toNone => jay

    Back to the top


    Powered by Savane 3.5