Thanks for the suggestion.

mlocate is not a heavy-weight full-text search system, it was designed to minimize impact on system caches, by
* Only reading directories, not metadata or contents of individual files
* Not even rereading a directory when its modification time has changed

As such, it would be obviously out of scope to index contents of regular files. Similarly, what a symbolic link "points to" is, conceptually, its content (and, depending on the length of the data and the file system, may even be stored as such).

On the other hand, some file systems do store symbolic link contents in directories, and symbolic links are probably rare enough that rereading a directory when its modification time has changed ''or'' it contains a symlink wouldn't have that much of a performance impact.

I'd expect (without hard data) searches for symbolic link contents to be fairly infrequent.

So - it's not a simple decision, however on balance I think it's more in line with the purpose of mlocate not to index contents of symbolic links.

(Ordinarily the suggestion when rejecting a mlocate feature is to use a full-text indexing system like tracker, but those tools are not terribly likely to index system-level objects like symbolic links. Still, I'd expect searches for symbolic link contents to be fairly infrequent.)