Un avertissement concernant l'utilisation du bypass pour supprimer une ancienne sauvegarde : si la sauvegarde supprimée contient des dossiers qui sont exactement les mêmes dans des sauvegardes antérieures ou ultérieures, alors la commande les fichiers peuvent être supprimés de sauvegardes antérieures ou postérieures également !
Time Machine utilise non seulement des liens en dur pour les fichiers inchangés, mais aussi des liens en dur 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, la suppression de n'importe quel fichier de l'application /2014-11-06/folder/ est bien, et n'affecte que la sauvegarde pour cette date. Le nombre de références de lien dur est réduit, donc le " inode " pour file2 seront supprimés, mais les inodes pour file1 y file3 aura toujours un nombre de référence de 1 à cause des sauvegardes ultérieures. Par conséquent, rm -R /2014-11-06 est bien aussi.
Cependant, la suppression d'un fichier de l'un ou l'autre /2014-11-13/folder/ , /2014-11-20/folder/ o /2014-11-27/folder/ le supprimera effectivement de ces 3 dossiers.
Le problème est que rm -R ne se soucie pas des dossiers à lien dur. Il se contente de récurser dans n'importe quel dossier lié en dur qu'il trouve, supprime audacieusement tous ses fichiers, puis supprime le dossier vide.
Donc : lors de la suppression d'une ancienne sauvegarde, il ne faut pas faire une récursion dans un dossier lié en dur et supprimer son contenu. Au lieu de cela, il faut seulement supprimer le lien dur pour le dossier lui-même. . Donc, plutôt que de rm -R utiliser tmutil delete comme expliqué dans la réponse d'Arne .
Soit dit en passant, il semble que l'OS X unlink commande ne peut pas être utilisé sur les dossiers : "un seul argument, qui ne doit pas être un répertoire, peut être fourni" . L'API d'OS X peut supprimer les dossiers à lien dur, tout comme l'API d'OS X peut supprimer les dossiers à lien dur. GNU Coreutils comme installé en utilisant Homebrew .
Enfin, pour prouver tout ce qui précède, un cas-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 de 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 délié l'un des fichiers, le nombre de liens est tombé à 1 pour chaque occurrence, bien que le fichier soit toujours affiché 3 fois. Aucun problème pour l'instant. 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, ils sont tous partis. Apparemment, le fichier TopSites.plist a été modifié pour la dernière fois le 2014-11-06 et mis en ligne le 2014-11-13, car d'autres fichiers ont été ajoutés, modifiés ou supprimés dans la base de données. Safari dossier. Ensuite, le contenu du dossier Safari n'a pas été modifié dans les deux sauvegardes suivantes, de sorte que le 20 novembre 2014 et le 27 novembre 2014, le dossier Safari é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//
