• [^] # Re: Précaution

    Posté par . En réponse au message locate et home chiffré. Évalué à 2.

    Sinon, sans compromis: il peut utiliser l'option -U, --database-root PATH de updatedb (ainsi que -d, --database DBPATH de locate, bien sûr) pour mettre la base de données dans son $HOME, ce qui à mon humble avis est nettement plus propre que de mettre un truc relatif à des données utilisateur dans une partition système.
    Accessoirement, s'il mets ça dans ses fichiers utilisateurs, le mécanisme sera portable et plus performant:

    • plus performant parce que pour un disque mécanique il y aura moins de déplacements des têtes de lecture;
    • plus performant parce que j'ose imaginer que locate ne charge pas tous les fichiers quand ils sont segmentés (et, pour le coup, ça serait bien une segmentation par «zones», on peut espérer que locate n'ira pas chercher dans la db de /usr quand l'utilisateur cherche un fichier dans /home?);
    • plus performant parce que l'on peut supposer que seul le $HOME nécessite une mise à jour sans événement scripté (genre un apt update ou apt install)
    • plus portable parce que le $HOME sera un peu plus indépendant du système (donc, il pourra être trimbalé d'une machine à une autre avec moins de conséquences... en supposant que le locate de l'autre système supporte les mêmes options, bien sûr).

    Si tu as un SSD tu peux te dispenser de locate et plutôt utiliser find.

    C'est aussi vrai s'il crée souvent des fichiers: find n'a pas besoin de mettre à jour une base, même s'il est plus lent. Personnellement, je sais que je n'utilise jamais locate, pour cette raison. Après... je devrais peut-être, peut-être qu'il est plus simple de trouver un truc avec locate en excluant un dossier et ses enfants (je crains que je ne comprendrais jamais comment marche --prune... :/)