Réponses:
Essayer:
sudo /usr/libexec/locate.updatedb
Et config look:
/etc/locate.rc le fichier de configuration
Édité:
Poster ici la sortie:
echo $LOCATE_CONFIG
Et:
cat /etc/locate.rc
Et:
echo $0
Mise à jour:
Le programme de localisation recherche dans une base de données tous les noms de chemins correspondant au modèle spécifié. La base de données de la base de données est recalculée périodiquement (généralement une fois par semaine ou quotidiennement) et contient les chemins d'accès de tous les fichiers accessibles au public .
Essayez plutôt mdfind localiser
Mis à jour2:
texte mdfind -name qui est plus précis. Tout texte mdfind vous donne des fichiers qui contiennent du texte aussi bien. - David Krmpotic
mdfind -name text
mdfind -name text
laquelle est plus précise. Vous mdfind text
donne simplement des fichiers qui contiennent également du texte.
Les autorisations peuvent être le coupable car localiser ne peut apparemment pas lire les fichiers qui ne sont pas lisibles par le monde. Voir cette réponse de Plundra pour plus d'explications.
Le findutils package à partir homebrew ne permet gupdatedb
et les glocate
commandes qui semblent surmonter certaines des limites des services publics de BUILTIN.
mdutil
est-il judicieux de vérifier cela? Un cas d'utilisation , je peux penser est que je peux déclencher rescan manuellement gupdatedb
- Spotlight pas si facile ou il prendrait plus de temps (il aussi indexe les fichiers contenus). Y at - il d' autres avantages?
updatedb
est plus rapide pour ça. glocate
semble avoir aucun fichier système d'indexation des problèmes, alors que je trouve mdfind
ignores ~ / Library et d' autres fichiers système. Je trouve vraiment que je reçois plus de coups avec glocate
plus mdfind
dans la plupart des cas. YMMV.
sudo gupdatedb
, puis j'ai enregistré la glocate Radium
sortie. Ensuite, j'ai couru gupdatedb
et il a dit:, /.Trashes: Permission denied
la même chose pour certains autres dossiers. J'ai comparé la sortie pour les deux et c'était la même chose! Étrange ...
sudo gupdatedb
(en l'exécutant en tant que root), puis vous avez suivi plus tard en exécutant en gupdatedb
tant qu'utilisateur normal qui n'aurait pas accès aux fichiers auxquels l'utilisateur root aurait accès, ce qui signifie que vous obtiendriez autorisation refusée erreurs. Si vous voulez une base de données complète des noms de fichiers pour votre système, continuer à fonctionner en tant que root. Cela expose vos fichiers à d'autres utilisateurs du système qui peuvent utiliser la glocate
commande. Mais si vous êtes le seul utilisateur, ça devrait aller.
#SEARCHPATHS="/"
dans la configuration, il n'a pas aidé.-v
L'option ne semble pas produire de sortie supplémentaire: /