Currently Being ModeratedJan 3, 2013 6:29 AM (in response to ofer4)
I suggest you edit /etc/locate.rc to comment out the existing PRUNEPATHS assignment and add something like the following (some lines may not apply):
Currently Being ModeratedJan 3, 2013 6:48 AM (in response to Linc Davis)
Thanks for the reply, Linc. I tried your suggestion. First, I should note that all lines of locate.rc were commented out, by default, including the PRUNEPATHS line.
I made my PRUNEPATHS variable as
PRUNEPATHS="/tmp /var/tmp /Users /Volumes /private/tmp /private/var /.DocumentRevisions-V100 /.PKInstallSandboxManager /.Spotlight-V100 /.Trashes /.fseventsd /.vol"
This setting is obviously overly aggressive, but for testing purposes, I thought I'd see what it would do. I removed locate.database first, then ran /usr/libexec/locate.updatedb again. No luck...same error.
As a testing tool, I then even tried:
PRUNEPATHS = "/"
Again I removed the existing locate.database, rebuilt it (very short now!). Same error. So, even when the database should be blank, it is still corrupt. Something appears to be very wrong with the manner in which the database is being built.
Currently Being ModeratedJan 3, 2013 9:02 AM (in response to Linc Davis)
As far as I know, it's straight out of the box. It was one of the first commands that I used after booting for the first time, and while the database wasn't yet set up at that point, the error appeared upon first use after building the db.
Some googling before posting showed this error appearing sporadically (almost always OS X users), going back up to 5 years.
I was just going to link to one of these posts, and I stumbled upon a different one here: https://discussions.apple.com/thread/1249883?start=0&tstart=0 . Based on this linked discussion, I unset the $LOCATE_PATH environment variable, rebuilt the database (reverting to default locate.rc), and voila! Success!
The LOCATE_PATH variable was, for some reason, set to /Users/ryan . On my linux box, this variable is not set by default. I still don't fully understand why this variable causes a problem, but setting it to [blank] seems to fix things. I'd love some insight from someone concerning the underlying breakage so that we can fix this issue permanently. For now, I can easily change the environment variable in my .cshrc .
Linc, just out of curiosity, is this variable set for you?
Currently Being ModeratedJan 3, 2013 9:31 AM (in response to Linc Davis)
Based on this response, I did a little more digging. Apparently I had set LOCATE_PATH to $HOME in my .cshrc . (My .cshrc was copied over from a shared computing cluster, in which this variable was necessary to avoid indexing the whole cluster.) I'm still not sure why setting it breaks things in OS X, but for now, I'll consider it resolved for my purposes.
Just to be clear for anyone else that runs into this issue... I simply had to comment out the line in my .cshrc that set the LOCATE_PATH variable, remove the existing database in /var/db, and rebuild via /usr/libexec/locate.updatedb .
Linc, thanks for tracking this down with me...much appreciated!