trying to "locate" a solution
 

My locate.database won't update when I run

Currently it shows as being 256k in size under ls -l, but is actually empty if I do

on it. I've tried simply deleting the database and rebuilding it but that didn't help.

Hints?

Try as root
 

sudo /usr/libexec/locate.updatedb

but the database is not /usr/libexec/locate.updatedb, it's
/var/db/locate.database

I neglected to add "sudo" when I pasted in the code, I did run it as root...and look at the first line of my original, I know that locate.database is the database...

Here's what it looks like right now:

256 bytes is rather small for a locate.database for the 10G of info I have on my HD.

Could the update app be broken?

/usr/libexec/locate.updatedb is just a csh script, so cat it (or do a more on it) and see if it looks intact. Your first post implies that the locate.updatedb script itself is empty.

mine is:

If it looks ok, then try a

sudo csh -x /usr/libexec/locate.updatedb

which will turn tracing on and see if that sheds any light on what is happening. The script is only 3k or so, so if yours is toast, I can post or email it to you.

Cheers,
Doug

Here's the output from the trace:
 

My /usr/libexec/locate.updatedb is about 3k, a good sign and I'm relieved to find it did something, but the output from the trace reveals no insight to my eyes:

Wed Feb 13 07:45:26 EST 2002
set SRCHPATHS = /
set LIBDIR = /usr/libexec
if ( ! 0 ) setenv TMPDIR /var/tmp
setenv TMPDIR /var/tmp
if ( ! 0 ) setenv DBDIR /var/db
setenv DBDIR /var/db
set FCODES = /var/db/locate.database
set path = ( /bin /usr/bin )
set bigrams = /var/tmp/locate.bigrams.21230
set filelist = /var/tmp/locate.list.21230
set errs = /var/tmp/locate.errs.21230
find / ( ! -fstype local -o -fstype fdesc -o -fstype kernfs ) -a -prune -o -print
tr / \001
sort -T /var/tmp -f
echo 0
tr \001 /
/usr/libexec/locate.bigram
sort -T /var/tmp
echo 0
uniq -c
sort -T /var/tmp -nr
awk { if (NR <= 128) print $2 }
tr -d \012
if { grep -s -v 0 /var/tmp/locate.errs.21230 } then
grep -s -v 0 /var/tmp/locate.errs.21230
/usr/libexec/locate.code /var/tmp/locate.bigrams.21230
chmod 644 /var/db/locate.database
rm /var/tmp/locate.bigrams.21230 /var/tmp/locate.list.21230 /var/tmp/locate.errs.21230
endif


Here are the last few lines of code from locate.updatedb (maybe some got pruned off?):

if { grep -s -v 0 $errs } then
printf 'locate: updatedb failed\n\n'
else
$LIBDIR/locate.code $bigrams < $filelist > $FCODES
chmod 644 $FCODES
rm $bigrams $filelist $errs
endif

If you ever get it working here's a tip:

Setup a crontab to update your db at regular intervals using:

/usr/libexec/locate.updatedb

Then use app called "locater" instead of Sherlock - much faster!

Yep, that looks right.

So, given that you do not see the error 'locate: updatedb failed'
we can assume that the logic is assuming that everything has succeded.

What I would do (if you are comfortable with an editor and sudo) is to comment out the second last line of the script out. IE

# rm $bigrams $filelist $errs

Then run it

% sudo /usr/libexec/locate.updatedb

then

% ls -l /var/tmp

Amongst other things, I see on my system:

-rw-r--r-- 1 root wheel 243 Feb 13 23:33 locate.bigrams.17504
-rw-r--r-- 1 root wheel 4 Feb 13 23:33 locate.errs.17504
-rw-r--r-- 1 root wheel 16349013 Feb 13 23:33 locate.list.17504

% cd /var/tmp
% cat locate.errs.17504
0
0
% more locate.list.XXXXXX
/
/.DS_Store
/.hidden
/.Trashes
/Applications
/Applications/.DS_Store
/Applications/Acrobat Reader 5.0
...
...

So, if you have nothing but 2 zeros in the locate.errs.XXXXX file and a big 'locate.list.XXXXX' then the find command is working in the locate.updatedb script. If it is empty, we know something is wrong with the find...

The bigrams file is not very big (on my system) and I don't have a clue what the text in it means! (I think it determines what some common path parts are so the locate.code program can reduce the size of the database)

So, if these files are there and look about like mine, then that just leaves the locate.code part, so try this:

% cd /var/tmp
% /usr/libexec/locate.code locate.bigrams.XXXXX <locate.list.XXXXX >my.database
% ll my.database
-rw------- 1 stetner wheel 1851009 Feb 13 23:49 my.database


So let us know if you get some error or a small file again

Don't forget to uncomment the rm line when you are done testing!

Cheers,
Doug

Someone has actually wrapped a GUI around "locate" for use from the Finder...I was hoping to try it once this was straightened out.

The GUI is what I am talking about - called "locator". Great small footprint app - but you still have to update the locate db. Thus I wrote the crontab to do the work. BTW - that needs to be run inthe system crontab.

Get the GUI locator here:

http://www.sebastian-krauss.de/locator/

ok, now we're getting somewhere, these files do not exist in my /var/tmp:

locate.bigrams.21230
locate.errs.21230
locate.list.21230

And it looks like the locate.updatedb is loading some variables from them...I tried merely adding them with "mkfile" but of course they would be empty and give the same result.

So I wonder if I can pop some initial values into one/all of those files there to get a totally new /var/db/locate.database generated...

Just a guess, based on what Doug's having you unravel above: I don't suppose you are using the fink version of "find"? That is, maybe it's worth hard-coding the path to find into the script for updating the db.

In /usr/libexec/locate.updatedb

change the line that reads

find

to instead begin with

/usr/bin/find

and maybe things'll just work. (Don't forget to take out that comment from the "rm" line that you modified above.)

Cheers, and good luck,
Paul

ps "Locator", the gui app, is very nicely done. It introduces case insensitivity and regexp searches to locate, by issuing something like the command

% locate \* | perl -ne 'print if /my_regexp/i;'

behind the scenes. Here "my_regexp" is whatever's entered into the relevant text field in the GUI app. But it's definitely well worth having around the place, particularly if your fluency in "regex" is either up to scratch or in the process of being developed.

OK, got more info...

commented out the recommended line, and after running locate.updatedb again:

locate.errs.XXXXXXX

has

0
0

in it, while

locate.list.XXXXXXX

remains empty. That said locate.database IS getting updated after running locate.updatedb as confirmed by doing ls -l on the directory where locate.database lives. But it remains empty of content.

BTW, adding the explicit path to the find command made no difference.

What I did
 

I had this problem a few days ago, I couldn't figure out why the heck the database kept turning up empty and the locate.updatedb script took an unusually short amount of time (it usually took around 5 minutes or more before). What I ended up doing is downloading the latest version of findutils from GNU and installing that, and then just replacing the old locate app with the one I installed. The newer locate app works differently, has a different database format, and has a different database update script that's now installed in /usr/bin, so I changed the /etc/weekly program to reflect the new one. It may not have been the best thing to do, but the new locate seems a tad faster at rebuilding the database, and I figured there was no point messing with the old locate when it was simple to install a new one. The install was straightforward (./configure : make : sudo make install) I think, though I may have put -flat_namespace in the CFLAGS environment variable.

~BC

If you want to use fink you can install:

findutils 4.1-4 Tools for searching for files

From the fink info fileutils:
......
locate's helper programs are stowed away in .../lib/locate. That's a
bit more difficult than usual because the configure script is really
old.

The package installs a daily cron job to update locate's
database

Cheers...

Fixed!

First I must thank all of you for your help, although the solution was outside of the direction we were all going in, the you all suggestions made helped illuminate for me the inner workings of my system.

This morning I rereading this thread for the billionth time and trying the suggested fixes again...I even snooped around my 10.1 install disk with Pacifist to see if I could just reinstall "locate" somehow. I wasn't having any luck. Then a dim light went on in my head...

So what was it?

Well, I run shxd which is a CLI-launched Hotline server clone that I run as a background app. When installing a recent update, I also installed Darwin GNU Find 4.1 so that searches of the server could be done from the client (this was a suggestion from the maker of shxd)...well I had installed it and never tried it and simply did not associate "find" with "locate" for some reason when later I found the locate command not functioning.

The fix was simply uninstalling Darwin GNU Find 4.1.

Oh, and the GUI app Locator is great, Sherlock will be collecting dust now.

Thanks again!

Hi Rusto,

does this mean that the fileutils version of "find" was in a package that caused it to *overwrite* the system version? That would be a pretty dirty trick, and should be stamped on rather quickly.

(Reason I ask is because it'd be nice to know why my suggested fix above didn't do the trick, when what you write suggests that it probably should have. Unless you put in the full path to the gnu find maybe, instead of '/usr/bin/find' as suggested above?)

Thanks for any clarification, and best wishes,
Paul

Ya, I don't get it...I did insert the /usr/bin/find as you suggested and it had no effect...and I agree, it stinks that it messed with locate.

Okay, I know this is an old thread, but it was happening to me. This thread was one of the few google results I got, and it didn't help me. But I figured out what my problem was yesterday.

The problem is that the user id "nobody" can't write to /tmp.

I looked at my /tmp and it was (IIRC) chmod 755. That was strange, because /tmp is usually supposed to be 777. Then I noticed something else. /tmp is normally a symbolic link to /private/tmp, but mine was a directory!

Everything worked fine after I fixed the /tmp directory. The commands should be something like this:

(double post)

Since you didn't show those commands preceded by a 'sudo', it seems that you were logged in as 'root'.
It was likely some previous misadventure as 'root' that resulted in the /tmp symlink getting blown away and replaced by a directory.
Best to avoid 'root' - just use 'sudo' as needed.