Où vont les fichiers lorsque la commande rm est émise?

Récemment, j’ai fait accidentellement rmune série de fichiers et cela m’a amené à penser à la place exacte de ces fichiers?

C'est-à-dire que, lorsque vous travaillez avec une interface graphique, les fichiers supprimés sont placés dans la corbeille. Quel est l'équivalent rmet existe-t-il un moyen d'annuler une rmcommande?

Nulle part, disparu, disparu. Eh bien, plus spécifiquement, le fichier est dissocié. Les données sont toujours stockées sur le disque, mais le lien qui les relie est supprimé. Auparavant, il était possible de récupérer les données, mais à présent, les métadonnées sont effacées et rien ne peut être récupéré.

Il n'y a pas de poubelle pour rm, et il ne devrait pas y en avoir. Si vous avez besoin d’une corbeille, vous devez utiliser une interface de niveau supérieur. trash-cliUbuntu contient un utilitaire de ligne de commande , mais la plupart du temps, des gestionnaires de fichiers à interface graphique tels que Nautilus ou Dolphin sont utilisés pour fournir une corbeille standard. La poubelle est standard lui-même. Les fichiers supprimés dans Dolphin seront visibles dans la corbeille de Nautilus.

Les fichiers sont généralement déplacés quelque part, comme ~/.local/share/Trash/files/lors de la mise au rebut. La rmcommande sous UNIX / Linux est comparable à celle delde DOS / Windows qui supprime et ne déplace pas les fichiers vers la corbeille. Une autre chose à réaliser est que déplacer un fichier sur des systèmes de fichiers, comme sur votre disque USB, à partir de votre disque dur, est vraiment 1) une copie des données du fichier suivie de 2) la désassociation du fichier original. Vous ne voudriez pas que votre Corbeille soit remplie de ces copies supplémentaires.

Pour ext3 / ext4, vous pouvez essayer de récupérer des fichiers en utilisant des outils tels que extundelete ou ext3grep , ou même aller déconner avec les structures de bas niveau manuellement (pas pour les faibles de cœur); pour de nombreux systèmes de fichiers, vous pouvez essayer de rechercher les blocs non encore écrasés selon certains modèles (par exemple, magicrescue peut rechercher des en-têtes JPEG, entre autres). Notez qu’ils utilisent des méthodes heuristiques pour récupérer les fichiers à partir des métadonnées, la récupération totale n’est donc pas garantie. Il s’agit plutôt d’un pari de la dernière chance n'étaient pas encore écrasés).

Ainsi, à toutes fins utiles, les fichiers supprimés rmont disparu - vous pouvez essayer la nécromancie offerte par ces outils, mais ne vous en fiez pas: ce sont les outils à utiliser lorsque tout le reste échoue. Mieux vaut extraire vos dernières sauvegardes (vous avez fait des sauvegardes, n'est-ce pas? Eh bien, vivre et apprendre ...).

En ce qui concerne l'annulation des effets de rm:

Étant donné que la plupart des systèmes de fichiers suppriment uniquement la référence aux données et indiquent que les blocs sont libres, vous pouvez essayer de localiser vos données en les lisant directement à partir du périphérique. Avec un peu de chance, les blocs contenant votre fichier ne sont pas revendiqués pour autre chose.

Cela suppose que vous avez quelque chose d'assez unique à rechercher, que vous avez rootsur le système et que je suppose que rassembler tout ce qui couvre plus d'un bloc du système de fichiers (probablement 4 ko) risque de devenir assez laborieux si le système de fichiers ne le gère pas. mettre le fichier (s) dans des blocs contigus.

J'ai réussi à récupérer le contenu de quelques fichiers en texte brut en exécutant des chaînes sur le périphérique sur lequel se trouvait le système de fichiers et en greprecherchant un élément parmi ces fichiers avec un contexte large ( -C). (Et peu de temps après cet incident, la société a décidé de consacrer des ressources à la mise en œuvre de sauvegardes)

Chaque fois que vous supprimez un fichier à l'aide de la rmcommande, les données du fichier ne sont jamais supprimées. En d'autres termes, les blocs du système de fichiers contenant des données sont toujours présents.

En réalité, lorsque vous exécutez la rmcommande, le système marque l'inode appartenant à ce fichier comme étant inutilisé et les blocs de données de ce fichier comme inutilisés (sans les effacer). Cependant, la ext3plupart des champs de l'inode sont mis à zéro, lorsqu'un fichier est supprimé.

Ce marquage normal de non utilisé est fait pour la vitesse ... Sinon pour la suppression cela prendra un peu plus de temps. C'est pourquoi vous avez peut-être remarqué que même la suppression de fichiers volumineux est plus rapide (vous pouvez récupérer les données si les blocs de données ne sont pas écrasés).

Plus d'infos: Structure d'Inode , Comment fonctionne la suppression de fichier

Dans les systèmes de fichiers de style Unix (y compris sous Linux), les fichiers ne sont pas vraiment "à" un endroit particulier. Au lieu de cela, le système utilise des liens physiques pour pointer en gros morceaux de données. Ainsi, lorsque vous créez un fichier, vous créez également son premier lien dur: celui qui réside réellement à l'emplacement où vous avez "enregistré" le fichier. Si vous créez plus de liens physiques, le fichier existe réellement à plusieurs endroits à la fois, à la connaissance du système.

Lorsque vous "supprimez" un fichier, vous ne supprimez normalement que le lien physique qui existait à l'emplacement que vous avez spécifié. C'est pourquoi l'appel système à supprimer des fichiers est appelé unlink(). Le système ne supprimera pas le fichier tant qu'il ne restera plus aucun lien physique. Mais une fois que ce dernier lien dur est détruit, les données le sont également.

Alors, où vont les fichiers que vous supprimez? S'il y a encore des liens durs, leurs fichiers se trouvent où se trouvent les liens durs que vous n'avez pas supprimés. S'il ne reste aucun lien dur, les fichiers sont partis.

Regardez aussi dans ~ / .snapshot si le fichier a été récemment supprimé.