Antichesse (o ^ω^ o)
Mon / est blindé il faut donc que je fasse de la place ailleurs, par exemple sur ma partition /home. Puisque j'ai récupéré tout un tas d'images depuis des mois, j'ai mis au point une solution abrupte mais qui fonctionne :P
Comment ai-je fait ?
- Arrêter le démon Docker.
- Déplacer le contenu du dossier
/var/lib/dockerdans/home/docker. - Supprimer
/var/lib/docker. - Créer à la place un lien symbolique qui pointe vers
/home/docker. - Redémarrer le démon Docker.
Je viens de percuter qu'en Rust, les TU sont dans le même fichier que celui du source à tester à ceci près qu'ils sont dans un module appelé tests... J'ai failli vomir sur le coup !
On a quand même bientôt 20 années de Maven et Gradle, ou de Composer et Symfony, ou encore presque une décennie de npm/yarn et Karma, de rake et Ruby, de pyb et Python ; et des gens n'ont toujours pas compris qu'il y avait une différence entre les sources qu'on livre et celles qui servent à fabriquer les sources qui vont être livrées. De la même manière qu'il ne faut pas générer les binaires dans le répertoire ./src il ne faut pas mélanger le code de ses TU avec celui de son programme, idem pour les ressources des tests et du programme.
Il n'y a pas à dire, l'univers des langages bas niveau (C/C++/Rust/Go/etc) est d'une pauvreté en terme de méthodologie, c'est incroyable ! D'autant qu'une bonne partie des personnes y œuvrant se prends systématiquement pour des cadors, j'ai de la peine pour eux et encore plus pour ceux qui doivent faire avec...
Bref, pour des raisons évidentes d'hygiène je vais détourner le répertoire des TI en TU si c'est possible de le faire...
EDIT : l'arborescence standard d'un projet Rust.
.
├── Cargo.lock
├── Cargo.toml
├── src/
│ ├── lib.rs
│ ├── main.rs
│ └── bin/
│ ├── named-executable.rs
│ ├── another-executable.rs
│ └── multi-file-executable/
│ ├── main.rs
│ └── some_module.rs
├── benches/
│ ├── large-input.rs
│ └── multi-file-bench/
│ ├── main.rs
│ └── bench_module.rs
├── examples/
│ ├── simple.rs
│ └── multi-file-example/
│ ├── main.rs
│ └── ex_module.rs
└── tests/
├── some-integration-tests.rs
└── multi-file-test/
├── main.rs
└── test_module.rs
Pour @Chlouchloutte qui souhaite scanner le contenu d'un disque depuis une page web.
Attention, le scanne se limite à ce que l'utilisateur a bien voulu dévoiler à l'application. Aussi, il faut faire un bouton qui demande à l'utilisateur quels répertoires il souhaite scanner (et je ne sais pas si un répertoire est accepté à l'image d'un "open file").
Je cite :
Ça c'est l'un des gros gros points noirs de Linux: Les myriades de fichiers cachés (commençant par un point) que les applications utilisent pour stocker leurs données (configuration, etc.) dans chaque répertoire utilisateur.
Même si les fichiers ne sont pas visibles, c'est un énorme bordel.
En tant que développeur, il y a pourtant des règles à suivre pour limiter ce chantier ($XDG_DATA_HOME/$XDG_CONFIG_HOME/$XDG_CACHE_HOME...).
Sous Linux, umask est la configuration qui détermine quels seront les droits attribués par défaut, que porteront de vos fichiers et vos répertoires, lors de leur création.
Un site qui semble fournir plein de tutos. (Je n'ai pas fouillé)
Vous administrez un Linux exposé sur internet (ou ailleurs), alors il est vivement recommandé de poser des options de montage sur vos répertoires /tmp et /var/tmp.
Voici un article expliquant comment les sécuriser.