id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
118	updatedb from findutils-4.4.2-6.oc00.pentium4 has hardcoded (incorrect) paths and other issues	Lewis Rosenthal		"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. :-("	defect	closed	major		*none		high	fixed