Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Mac "locate" database corrupt

Hi, folks -


I frequently use the terminal, as well as the "locate" command within the terminal. Unfortunately, this rather standard functionality does not appear to work in 10.8.2 . When I run the locate command, I receive, for example:


> locate afile

locate: locate database header corrupt, bigram char outside 0, 32-127: -1


Based on suggestions in old forums elsewhere, I deleted (moved) the /var/db/locate.database file. I then re-made the database using "sudo /usr/libexec/locate.updatedb". After some time, the database is re-created, but the error persists.


Any thoughts?


Thanks -

Ryan

MacBook Pro with Retina display, OS X Mountain Lion (10.8.2)

Posted on Jan 2, 2013 10:09 PM

Reply
Question marked as Best reply

Posted on Jan 3, 2013 6:29 AM

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):


PRUNEPATHS=\

"

/.DocumentRevisions-V100

/.MobileBackups

/.Spotlight-V100

/.Trashes

/.fseventsd

/Groups

/Shared\ Items

/Users

/Volumes

/private/tmp

/private/var

"

6 replies
Question marked as Best reply

Jan 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):


PRUNEPATHS=\

"

/.DocumentRevisions-V100

/.MobileBackups

/.Spotlight-V100

/.Trashes

/.fseventsd

/Groups

/Shared\ Items

/Users

/Volumes

/private/tmp

/private/var

"

Jan 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.

Jan 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?


Thanks!

Jan 3, 2013 9:31 AM in response to Linc Davis

Ok, thanks.


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!

Mac "locate" database corrupt

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.