rm : ce que « supprimer » veut dire, et ce que ça ne veut pas dire

Vous avez supprimé des milliers de fichiers. Vous n’avez probablement jamais lu ce que fait la commande qui les supprime. Elle tient en trois lettres, elle date de 1971, et elle ne fait pas ce que son nom laisse croire.

Ce que le manuel dit depuis toujours

Ouvrez un terminal et tapez man rm. La première ligne, celle qui donne le nom de la commande et sa raison d’être, dit ceci :

rm, unlink -- remove directory entries

Pas « remove files ». Remove directory entries : retirer des entrées de répertoire. La nuance a l’air d’un détail de traducteur. C’est en réalité toute l’affaire.

Un répertoire, dans un système de fichiers Unix, n’est pas une boîte qui contiendrait des fichiers. C’est une table de correspondance : d’un côté des noms, de l’autre des numéros. Le numéro s’appelle un inode, et c’est lui qui pointe vers les données réelles, quelque part sur le disque. Le nom lettre.txt n’est pas le fichier. C’est une étiquette collée dessus.

rm décolle l’étiquette.

Un fichier qu’on lit après l’avoir supprimé

Ça se vérifie en dix lignes. J’ai écrit un fichier de 2 840 octets, je l’ai ouvert, puis je l’ai supprimé pendant qu’il était ouvert, et j’ai continué à le lire.

=== 2. On l'OUVRE, puis on le supprime pendant qu'il est ouvert ===
   le nom existe encore ?   False
   ls du dossier         :  []
   LU APRES SUPPRESSION  :  2840 octets
   identique a l'original ? True

Le dossier est vide. ls ne montre rien. Le nom a disparu du système. Et les 2 840 octets sont là, entiers, identiques au premier.

En regardant l’inode de plus près, on voit exactement ce qui s’est passé :

   meme inode ?      True ( 49275700 )
   nombre de liens :  0   <- zero nom, mais un descripteur ouvert
   taille          :  2840

Un fichier avec zéro nom. Il existe, il a une taille, il se lit, et aucun chemin sur la machine ne mène à lui. Il n’est plus atteignable que par le programme qui l’avait ouvert avant sa disparition.

La spécification le dit noir sur blanc, dans man 2 unlink :

« If one or more process have the file open when the last link is removed, the link is removed, but the removal of the file is delayed until all references to it have been closed. »

Traduction : la suppression est différée jusqu’à ce que le dernier programme lâche prise.

Trois cents mégaoctets qui refusent de revenir

C’est là que ça devient concret pour qui a déjà vu un disque plein sans comprendre pourquoi. J’ai écrit 300 Mo, je les ai supprimés sans fermer le fichier, et j’ai regardé l’espace libre.

libre au depart                : 1584652.8 Mo
apres ecriture de 300 Mo       : 1584352.8 Mo  -> consomme 300.0 Mo
APRES rm, fichier encore ouvert: 1584352.8 Mo  -> rendu -0.0 Mo
   le nom n'existe plus : True
apres fermeture du descripteur : 1584652.8 Mo  -> rendu 300.0 Mo

Zéro octet rendu par la suppression. Trois cents mégaoctets rendus d’un coup à la fermeture.

C’est l’explication d’une scène que tout administrateur a vécue : un journal d’application grossit, on le supprime pour faire de la place, et le disque reste plein. Le fichier n’a plus de nom, mais le programme qui écrit dedans le tient toujours ouvert. Tant qu’il ne redémarre pas, l’espace ne revient pas. On peut supprimer autant qu’on veut, on ne récupère rien.

Un fichier qui a deux noms

Dernière démonstration, et la plus parlante sur ce qu’est vraiment un fichier. On peut donner deux noms à un même contenu, c’est ce qu’on appelle un lien dur.

   nom-a liens : 2 | nom-b liens : 2
   meme inode  : True
   apres rm nom-a : nom-b existe ? True | liens restants : 1
   contenu de nom-b : deux noms, un seul contenu

rm nom-a n’a rien détruit. Il a décrémenté un compteur, de 2 à 1. Le contenu n’est effacé que lorsque ce compteur atteint zéro et que plus personne ne tient le fichier ouvert.

Ce compteur porte un nom : st_nlink. C’est lui, le vrai décideur. Pas vous, pas rm.

Ce qui a changé, et personne ne l’a dit dans le même article

Là où ça devient intéressant, c’est que la suite de l’histoire, celle que tout le monde connaît, a été retournée deux fois en quinze ans, et dans des directions opposées.

La vérité de 1995 : les données restent sur le disque après suppression, et un logiciel de récupération les retrouve. C’est ce qu’on répète depuis trente ans, et c’était vrai des disques à plateaux.

Premier retournement, le TRIM. Sur la machine où j’écris, un SSD Apple AP4096R, la commande TRIM est active. Quand le système libère des blocs, il le signale au disque, qui les efface pour de bon en arrière-plan, sans qu’on le lui demande. Les données ne traînent plus en attendant d’être écrasées : elles sont réellement détruites, souvent en quelques minutes. Le SSD efface mieux que le disque dur d’avant.

Second retournement, les instantanés. APFS sait figer l’état complet d’un volume à un instant donné, sans le copier. Un fichier supprimé qui se trouve dans un instantané est intégralement là, récupérable, et le compteur de liens n’y change rien. Sur cette machine, il y en a trois :

com.apple.os.update-DD664871BF4C124F7E98F2DFADED7241...
com.apple.os.update-E665088689556947ADF621B0053B4CA1...
com.apple.os.update-MSUPrepareUpdate

Ceux-là datent de mises à jour système. Mais Apple documente que Time Machine, quand la sauvegarde automatique est activée, en fabrique un par heure et les garde 24 heures. Sur cette machine précise, Time Machine n’a aucune destination configurée, donc ces instantanés horaires n’existent pas. Sur la vôtre, c’est probablement l’inverse.

Le résultat est le suivant, et il est inconfortable : le même geste, sur deux machines de la même année, peut détruire une donnée en trois minutes ou la conserver intacte pendant vingt-quatre heures. Ce n’est pas rm qui décide. Ce sont des réglages que la plupart des gens n’ont jamais ouverts.

Où je m’arrête

Je voulais savoir si la vieille phrase « un fichier supprimé n’est pas vraiment effacé » tenait encore. La réponse honnête, c’est qu’elle ne tient plus, et que son contraire non plus.

Ce que j’ai vérifié tient debout : rm retire un nom, pas des données ; l’espace n’est rendu qu’à la fermeture du dernier descripteur ; le contenu survit tant que le compteur de liens n’est pas à zéro. Ça, c’est du POSIX, c’est écrit, c’est mesurable, et ça ne bougera pas.

Ce qui vient après, la persistance réelle des octets sur le support, je ne peux pas le trancher pour votre machine. Je peux seulement dire que la question ne se pose plus du tout dans les termes où on la posait, et que les deux réponses toutes faites, « c’est effacé » et « c’est récupérable », sont fausses toutes les deux.

Il y a une leçon plus petite et plus sûre, celle que je garde. Pendant des décennies, la commande a dit exactement ce qu’elle faisait, en cinq mots, en première ligne de son manuel. remove directory entries. Personne ne l’a lue, et tout le monde a passé trente ans à discuter d’autre chose.