on m'a demandé si il y a une solution pour tester sur un disque si des fichiers sont corrompus.
La solution fiable, comparer avec l’original si c’est une sauvegarde, la sauvegarde si c’est l’original (avec diff -r par exemple).
Sinon, vérifier le checksum si on en a un (ça m’arrive d’en faire ; sinon, même si on a une sauvegarde, le jour où l’original et la sauvegarde diffèrent, à moins d’avoir eu un problème clair avec un des disques, c’est difficile de savoir quelle version est la bonne).
En dernier recours, si le disque est montable sans faire de fsck, le monter en lecture seule et faire une copie des fichiers. Une erreur devrait s’afficher pour les fichiers incohérents... mais pas forcément pour les fichiers incomplets (un fichier peut être incomplet, mais cohérent, selon le moment où l’écriture a été interrompue). Bon, je ne sais pas si ça mènera très loin.
Un fsck devrait permettre de récupérer certains fichiers grâce au journal (pour un système de fichiers journalisé), mais d’autres resteront certainement incomplets (ou carrément absents s’ils n’ont été écrits que dans le cache avant déconnexion du disque), même si a l’arrivée, il seront tous rendus cohérents du point du vue du système de fichiers.
Ça peut être intéressant de regarder les dates de modification des fichiers, mais la date n’est peut-être mise à jour qu’à la fin d’une écriture...
Suivant le format d’un fichier, certains logiciels destinés à lire ce format afficheront sur la sortie d’erreur (pour peu qu’on les ait lancé en ligne de commande) si le fichier a été tronqué ou si son contenu est incohérent.
Bon, ce ne sont que quelques pistes, pas miraculeuses.
S’il y a eu un nombre assez important de déconnexions étalées sur une période assez longue, eh bien... bon courage !
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Fichier corrompu
Posté par Arthur Accroc . En réponse au message Récupération de données sous linux : ext2, ext3, ext4, .... Évalué à 2.
La solution fiable, comparer avec l’original si c’est une sauvegarde, la sauvegarde si c’est l’original (avec diff -r par exemple).
Sinon, vérifier le checksum si on en a un (ça m’arrive d’en faire ; sinon, même si on a une sauvegarde, le jour où l’original et la sauvegarde diffèrent, à moins d’avoir eu un problème clair avec un des disques, c’est difficile de savoir quelle version est la bonne).
En dernier recours, si le disque est montable sans faire de fsck, le monter en lecture seule et faire une copie des fichiers. Une erreur devrait s’afficher pour les fichiers incohérents... mais pas forcément pour les fichiers incomplets (un fichier peut être incomplet, mais cohérent, selon le moment où l’écriture a été interrompue). Bon, je ne sais pas si ça mènera très loin.
Un fsck devrait permettre de récupérer certains fichiers grâce au journal (pour un système de fichiers journalisé), mais d’autres resteront certainement incomplets (ou carrément absents s’ils n’ont été écrits que dans le cache avant déconnexion du disque), même si a l’arrivée, il seront tous rendus cohérents du point du vue du système de fichiers.
Ça peut être intéressant de regarder les dates de modification des fichiers, mais la date n’est peut-être mise à jour qu’à la fin d’une écriture...
Suivant le format d’un fichier, certains logiciels destinés à lire ce format afficheront sur la sortie d’erreur (pour peu qu’on les ait lancé en ligne de commande) si le fichier a été tronqué ou si son contenu est incohérent.
Bon, ce ne sont que quelques pistes, pas miraculeuses.
S’il y a eu un nombre assez important de déconnexions étalées sur une période assez longue, eh bien... bon courage !
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone