Avertissement concernant l'utilisation de la bypasscommande pour supprimer une ancienne sauvegarde: si la sauvegarde supprimée contient des dossiers identiques à ceux des sauvegardes précédentes ou ultérieures, les fichiers peuvent également être supprimés des sauvegardes antérieures ou ultérieures !
Time Machine utilise non seulement des liens physiques pour les fichiers non modifiés, mais également des liens physiques pour les dossiers dans lesquels aucun fichier n'a été ajouté, modifié ou supprimé. Cela donne quelque chose comme:
/2014-11-06/folder/file1
/file2
/file3
/2014-11-13/folder/file1 = hard link to file /2014-11-06/folder/file1
/file2 (changed; new inode)
/file3 = hard link to file /2014-11-06/folder/file3
/2014-11-20/folder/ = hard link to folder /2014-11-13/folder/
/2014-11-27/folder/ = hard link to folder /2014-11-20/folder/
Avec ce qui précède, supprimer n'importe quel fichier /2014-11-06/folder/est correct et n'affecte que la sauvegarde pour cette date. Le nombre de références de liaisons physiques est réduit, de sorte que "l' inode " file2sera supprimé, mais les inodes pour file1et file3auront toujours un nombre de références de 1 en raison des sauvegardes ultérieures. Par conséquent, rm -R /2014-11-06c'est bien aussi.
Cependant, supprimer tout fichier de l’un ou de l’autre /2014-11-13/folder/, /2014-11-20/folder/ou /2014-11-27/folder/le supprimera effectivement de tous ces 3 dossiers.
Le problème est que rm -Rpeu importe les dossiers liés. Il ne fait que récursir dans tous les dossiers durement liés qu'il trouve, efface hardiment tous ses fichiers, puis supprime le dossier vide.
Ainsi: lors de la suppression d'une ancienne sauvegarde, il ne faut pas recurse dans un dossier dur et supprimer son contenu. Au lieu de cela, vous ne devez supprimer que le lien physique du dossier lui-même . Donc, plutôt que d' rm -Rutiliser tmutil deletecomme expliqué dans la réponse d'Arne .
En passant, il semble que la unlinkcommande OS X ne puisse pas être utilisée sur des dossiers : "un seul argument, qui ne doit pas être un répertoire, peut être fourni" . L'API OS X peut supprimer les dossiers liés de manière rigoureuse, de même que GNU Coreutils , comme s'il était installé avec Homebrew .
Enfin, pour prouver tout ce qui précède, un scénario de test (OSX 10.6.8):
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist
Notez que le nombre de liens pour chaque occurrence est 2 (deuxième colonne). Supprimons la première occurrence:
sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist
Ainsi, après avoir dissocié l'un des fichiers, le nombre de liens est tombé à 1 pour chaque occurrence, même si le fichier est toujours affiché 3 fois. Pas de problèmes pour le moment. Supprimez à nouveau la première occurrence:
sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
ls: 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist: No such file or directory
Maintenant tous sont partis. Apparemment, le fichier a TopSites.plistété modifié pour la dernière fois le 2014-11-06 et lié en dur le 2014-11-13, à ce moment-là, certains autres fichiers ont été ajoutés, modifiés ou supprimés dans le Safaridossier. Ensuite, le contenu du Safaridossier n'a pas changé dans les deux sauvegardes suivantes. Ainsi, les 2014-11-20 et 2014-11-27, le Safaridossier était lié à la sauvegarde précédente.
En effet, les 4 dossiers n’utilisent que 2 inodes (première colonne):
sh-3.2# ls -lFaid 2014-11*/Users/USERNAME/Library/Safari/
648651968 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:06 2014-11-06-012454/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-13-024438/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-20-014044/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-27-025033/Users/USERNAME/Library/Safari//