Testé. Deux itérations possibles seulement. :–(
Après, cette engeance s'adapte. :–[
Je suis un traumatisé de l'intégration humain / machine depuis Captain Power.
Attention avec -exec car ça fork(2) pour chaque instance trouvée; ce qui péjore les perfs.
Un | xargs pourrait être ++rapide mais présente d'autres limites (soucis avec les espaces dans les chemins et taille de la ligne de commande par exemples).
Mention spéciale pour prll, sur environnements SMP; surtout avec du stockage SSD capable de tout plein d'iops.
Cogito, ergoseum.
TSA niveau 1 (ex-Asperger) dans contexte HPI (hétérogène) confirmé en CRA fin 2019.
Testé. Deux itérations possibles seulement. :–(
Après, cette engeance s'adapte. :–[
Je suis un traumatisé de l'intégration humain / machine depuis Captain Power.
Attention avec -exec car ça fork(2) pour chaque instance trouvée; ce qui péjore les perfs.
Un | xargs pourrait être ++rapide mais présente d'autres limites (soucis avec les espaces dans les chemins et taille de la ligne de commande par exemples).
Mention spéciale pour prll, sur environnements SMP; surtout avec du stockage SSD capable de tout plein d'iops.
Spoiler :
Excellentissime !! : ))
En situations conventionnelles, j'aurais privilégié l'emploi de la commande `locate`, suivant laquelle une inspection détaillée de chaque répertoire identifié aurait été entreprise. Néanmoins, dans le contexte actuel, la réticence à initier une mise à jour de la base de données via `updatedb` s'est manifestée, probablement en raison d'une inclinaison à éviter une tâche jugée superflue.
Sur le plan technique, il est impérieux de souligner que la réécriture incessante (2366 fois ^^) sur un support de stockage, spécialement lorsqu'il s'approche de son seuil d'obsolescence, ne contribue guère à une amélioration tangible de la performance ou de la durabilité, surtout dans le cas des disques à semi-conducteurs ou autres dispositifs à mémoire flash. Dans ces circonstances, une approche préconisée pour l'éradication sécurisée des données réside dans le chiffrement préalable des fichiers à l'aide d'une clé cryptographique de haute robustesse et générée aléatoirement, suivi par l'élimination du fichier crypté du système de fichiers. La suppression subséquente de la clé cryptographique entrave de manière significative la faculté de reconstitution des données chiffrées, les rendant ainsi inefficacement récupérables.
Il convient toutefois de reconnaître que la destruction physique du support de stockage demeure la méthode la plus infaillible en termes de sécurité des données.
L'adoption d'une stratégie combinant ces deux approches représentant le « St Graal » pour garantir une éradication irréversible des données.
Ps: J’ai lu avec intérêt que tu avais entrepris une excursion à pied et à moto durant le week-end écoulé. : )
Cette nouvelle a éveillé ma curiosité, ton périple s’est-il déroulé à travers les reliefs montagneux ? Ta monture mécanique était mue par une motorisation électrique ou bien par un moteur à combustion interne ?
(Je me trouve saisi d’une vive curiosité quant aux impressions et sensations que l’on peut éprouver en chevauchant une moto électrique.)
ASD (DSM-5)
Catch Me If You Scan or Buy Me a Phish & Chips.
ἕν οἶδα ὅτι οὐδὲν οἶδα. Σωκράτης
C3PO a écrit : ↑mardi 19 décembre 2023 à 0:56
En situations conventionnelles, j'aurais privilégié l'emploi de la commande `locate`, suivant laquelle une inspection détaillée de chaque répertoire identifié aurait été entreprise. Néanmoins, dans le contexte actuel, la réticence à initier une mise à jour de la base de données via `updatedb` s'est manifestée, probablement en raison d'une inclinaison à éviter une tâche jugée superflue.
Dans ses implémentations pas trop pariétales, j'ai cru constater que locate filtrait pour n'afficher que les fichiers pour lesquels on dispose des droits. Je ne saurais affirmer que son pendant updatedb soit accessible au vulgum pecus (id estuid!=0).
C3PO a écrit : ↑mardi 19 décembre 2023 à 0:56
Sur le plan technique, il est impérieux de souligner que la réécriture incessante (2366 fois ^^) sur un support de stockage, spécialement lorsqu'il s'approche de son seuil d'obsolescence, ne contribue guère à une amélioration tangible de la performance ou de la durabilité, surtout dans le cas des disques à semi-conducteurs ou autres dispositifs à mémoire flash.
Alors que sur un disque mécanique stockant des 1 verticaux « | » et des 0 horizontaux « — », on peut (pouvait ?) arriver à déterminer qu'un 1, pas tout à fait vertical « / », devait auparavant être un 0. Permettant ainsi de reconstituer tout ou partie des données effacées (dans les temps jadis avec un algorithme, aujourd'hui avec la trop souvent fallacieuse terminologie « IA » pour faire sérieux).
C3PO a écrit : ↑mardi 19 décembre 2023 à 0:56
Il convient toutefois de reconnaître que la destruction physique du support de stockage demeure la méthode la plus infaillible en termes de sécurité des données.
C3PO a écrit : ↑mardi 19 décembre 2023 à 0:56
Ps: J’ai lu avec intérêt que tu avais entrepris une excursion à pied et à moto durant le week-end écoulé. : )
Cette nouvelle a éveillé ma curiosité, ton périple s’est-il déroulé à travers les reliefs montagneux ? Ta monture mécanique était mue par une motorisation électrique ou bien par un moteur à combustion interne ?
(Je me trouve saisi d’une vive curiosité quant aux impressions et sensations que l’on peut éprouver en chevauchant une moto électrique.)[/spoiler]