C'est vrai, ça s'est amélioré, mais il reste toujours un gros problème : si j'ai bien compris, dans le système de fichiers ext2 (et donc ext3, je ne sais pas pour les autres), un inode ne contient pas le *nom* du fichier. Celui-ci est stocké sous la forme de « liens » dans des répertoires (d'où la possibilité d'avoir deux noms pour le même fichier et dont l'effacement de l'un ne provoque pas l'effacement du fichier : les liens « durs » créés à l'aide de la commande 'ln' sans l'option '-s'). Le problème de cette approche est que, lorsque le dernier lien vers le fichier a été unlink()é, on n'a plus qu'un inode avec un compteur de liens nul, et aucun moyen de savoir qui était ce fichier, ni son ancien emplacement !
Bon, si la commande que vous venez de taper était 'rm -f rapport_super_urgent.xml', et que vous vous rappelez peu ou prou sa taille, vous allez probablement être sorti d'affaire par e2recover et ses confrères. Mais personnellement, j'ai eu un magnifique plantage qui a effacé un *très* grand nombre de fichiers sur ma babasse (dont un certain nombre d'utilitaires système, au point que j'ai dû ressortir un vieux CD de DemoLinux et coller une partie des fichiers sur le HD pour convaincre la machine de se réamorcer). Sans connexion à l'Internet à ce moment, je me suis fait un script qui automatisait la procédure décrite dans le undeletion-howto... et je me suis retrouvé avec une tétrachiée de fichiers inconnus à recaser sur le disque. J'ai dû passer plus d'une semaine à regarder chaque fichier texte pour essayer de déterminer où il pouvait être originellement. Quant aux fichiers binaires, pour la plupart je n'avais que peu de moyens de savoir ce qu'ils étaient ('file' ne suffit pas toujours) donc très peu ont pu être récupérés.
Avec un système de fichiers qui mettrait juste un drapeau « effacé » sur le fichier pour signaler qu'on peut écrire par-dessus (FAT, par exemple), ce cauchemar ne serait pas arrivé. Bref, pour une fois, j'avoue que j'ai regretté les choix des concepteurs. Bien sûr, je ne suis pas un spécialiste des FS (en fait, j'y connais pas une bille, je suis même sûr que ce texte est bourré d'erreurs) et il doit y avoir de très bonnes raisons pour cette conception, mais des méthodes alternatives (par exemple, un répertoire '/.corbeille' qui contiendrait les chemins vers les anciens fichiers et leurs numéros d'inode, et qu'on pourrait utiliser pour la récupération ou au contraire purger de temps en temps) ne seraient peut-être pas inutiles dans tous les cas...
[^] # Re: Toujours en avoir sur soi !
Posté par William Steve Applegate . En réponse à la dépêche Tour d'horizon des distributions LiveOnCd. Évalué à 8.
Bon, si la commande que vous venez de taper était 'rm -f rapport_super_urgent.xml', et que vous vous rappelez peu ou prou sa taille, vous allez probablement être sorti d'affaire par e2recover et ses confrères. Mais personnellement, j'ai eu un magnifique plantage qui a effacé un *très* grand nombre de fichiers sur ma babasse (dont un certain nombre d'utilitaires système, au point que j'ai dû ressortir un vieux CD de DemoLinux et coller une partie des fichiers sur le HD pour convaincre la machine de se réamorcer). Sans connexion à l'Internet à ce moment, je me suis fait un script qui automatisait la procédure décrite dans le undeletion-howto... et je me suis retrouvé avec une tétrachiée de fichiers inconnus à recaser sur le disque. J'ai dû passer plus d'une semaine à regarder chaque fichier texte pour essayer de déterminer où il pouvait être originellement. Quant aux fichiers binaires, pour la plupart je n'avais que peu de moyens de savoir ce qu'ils étaient ('file' ne suffit pas toujours) donc très peu ont pu être récupérés.
Avec un système de fichiers qui mettrait juste un drapeau « effacé » sur le fichier pour signaler qu'on peut écrire par-dessus (FAT, par exemple), ce cauchemar ne serait pas arrivé. Bref, pour une fois, j'avoue que j'ai regretté les choix des concepteurs. Bien sûr, je ne suis pas un spécialiste des FS (en fait, j'y connais pas une bille, je suis même sûr que ce texte est bourré d'erreurs) et il doit y avoir de très bonnes raisons pour cette conception, mais des méthodes alternatives (par exemple, un répertoire '/.corbeille' qui contiendrait les chemins vers les anciens fichiers et leurs numéros d'inode, et qu'on pourrait utiliser pour la récupération ou au contraire purger de temps en temps) ne seraient peut-être pas inutiles dans tous les cas...
Envoyé depuis mon PDP 11/70