Opened 8 years ago

Closed 8 years ago

#118 closed defect (fixed)

updatedb from findutils-4.4.2-6.oc00.pentium4 has hardcoded (incorrect) paths and other issues

Reported by: Lewis Rosenthal Owned by:
Priority: major Milestone:
Component: *none Version:
Severity: high Keywords:
Cc:

Description

In short, updatedb does not work. After creating symlinks for frcode, bigram, and code in /@unixroot/usr/libexec (the initial complaints from updatedb run under latest dash), updatedb further complains:

# updatedb
C:/usr/bin/updatedb: 1: C:/usr/bin/updatedb: sed: not found
C:/usr/bin/updatedb: 243: C:/usr/bin/updatedb: rm: not found
C:/usr/bin/updatedb: 278: C:/usr/bin/updatedb: D:/usr/libexec/bin/sort.exe: I/O error
C:/usr/bin/updatedb: 292: C:/usr/bin/updatedb: chmod: not found
C:/usr/bin/updatedb: 293: C:/usr/bin/updatedb: mv: not found

I can confirm that D:/usr/libexec/bin/sort.exe is hardcoded in a few places in the script. With some more tweaking on my usual system, I am able to get updatedb to run (though no matter what I do, I cannot get it to find sed, rm, chmod, or mv, symlinks or no), however the resulting db (new format, not old) is apparently unusable:

[j:\usr]locate Overview
locate.exe: locate database `/@unixroot/var/locatedb' is corrupt or invalid

locatedb does appear to be a valid db, however, at least from the header. In fact, I am able to find a file located in the first line of it:

[j:\usr]locate 225022
/22502210.ZIP
locate.exe: locate database `/@unixroot/var/locatedb' is corrupt or invalid

The results are the same from any shell I've tried (dash, sh, bash, ash, CMD, 4OS2).

I know we've had issues with locate in the past. I was hoping these had been resolved. :-(

Change History (7)

comment:1 Changed 8 years ago by Silvan Scherrer

did you change the first line in the updatedb.sh to #! /@unixroot/usr/bin/sh
The updatedb.sh script needs a big overhaul it seems

comment:2 Changed 8 years ago by Lewis Rosenthal

;-)

You said:

did you change the first line in the updatedb.sh to #! /@unixroot/usr/bin/sh

No, but I actually *do* have /bin/sh on both volumes, for just such emergencies.

Changing it, and even starting from /@unixroot/usr/bin, seems to make no difference:

[j:\usr\bin]sh
# updatedb
J:/usr/bin/updatedb: 1: J:/usr/bin/updatedb: sed: not found
J:/usr/bin/updatedb: 243: J:/usr/bin/updatedb: rm: not found
J:/usr/bin/updatedb: 292: J:/usr/bin/updatedb: chmod: not found
J:/usr/bin/updatedb: 293: J:/usr/bin/updatedb: mv: not found
# locate bash
locate: locate database `/@unixroot/var/locatedb' is corrupt or invalid

(As mentioned earlier, I fixed the sort thing by adjusting the hardcoded paths in the script.) The result is the same, however.

comment:3 Changed 8 years ago by Silvan Scherrer

as I said, there is a lot more wrong in this script. Not only the hardcoded path, but also the PATH itself is exported wrong.

some of the errors:
add .exe to
: ${frcode:=${LIBEXECDIR}/frcode.exe}
: ${bigram:=${LIBEXECDIR}/bigram.exe}
: ${code:=${LIBEXECDIR}/code.exe}

and
PATH=/@unixroot/usr/bin;${BINDIR}; export PATH
: ${LIBEXECDIR=/@unixroot/usr/libexec}

If thats really all I don't know now. I know more when I updated findutils version to 4.6

comment:4 Changed 8 years ago by Silvan Scherrer

please try latest findutils from exp repo

comment:5 Changed 8 years ago by Lewis Rosenthal

Well, I now get:

# updatedb
Failed to generate /@unixroot/var/locatedb.n

which seems to be coming from:

if test -n "$NETPATHS"; then
myuid=`getuid`
if [ "$myuid" = 0 ]; then
    # : A3
    su $NETUSER `select_shell $NETUSER` -c \
     "$find $NETPATHS $FINDOPTIONS \\( -type d -regex '$PRUNEREGEX' -prune \\) -o $print_option" ||
    exit $?
  else
    # : A4
    $find $NETPATHS $FINDOPTIONS \( -type d -regex "$PRUNEREGEX" -prune \) -o $print_option ||
    exit $?
  fi
fi
} | $sort -f | $frcode $frcode_options > $LOCATE_DB.n
then
    : OK so far
    true
else
    rv=$?
    echo "Failed to generate $LOCATE_DB.n" >&2
    rm -f $LOCATE_DB.n
    exit $rv
fi

Even specifying a different output file fails to get past this one:

# updatedb --output=/@unixroot/var/newdb
Failed to generate /@unixroot/var/newdb.n

comment:6 Changed 8 years ago by Lewis Rosenthal

Hmmm... This is interesting from POPUPLOG:

10-08-2016  12:49:19  SYS2070  PID 017f  TID 0001  Slot 00e8
J:\USR\LIBEXEC\BIN\FIND.EXE
FIND->LIBCX0.___init_app
127
------------------------------------------------------------

10-08-2016  12:49:19  SYS2070  PID 0182  TID 0001  Slot 00fb
J:\USR\LIBEXEC\FRCODE.EXE
FRCODE->LIBCX0.___init_app
127

...and now, of course, the same script appears to be working - with no updates to anything else and no CONFIG.SYS changes. I wanted to try again to confirm the above FIND and FRCODE errors. I'll follow up when updatedb finishes.

comment:7 Changed 8 years ago by Lewis Rosenthal

Resolution: fixed
Status: newclosed

Yes, it worked.

It is possible that my earlier trouble was with my libcx update. I thought I rebooted after updating (again), but maybe I did not.

Bottom line: the script now works for me. I can update locatedb and locate works for the first time ever. Kudos!

Note: See TracTickets for help on using tickets.