Je souhaite supprimer certains fichiers/répertoires de ma partition Time Machine à l'aide de rm , mais je ne peux pas le faire. Je suis presque sûr que le problème est lié à une sorte d'attributs étendus de contrôle d'accès sur les fichiers de la sauvegarde, mais je ne sais pas comment les remplacer/les désactiver pour obtenir rm pour travailler. Un exemple d'erreur que je reçois est:
% Sudo rm -rf Backups.backupdb/MacBook/Latest/MacBook/somedir
rm: Backups.backupdb/MacBook/Latest/MacBook/somedir: Directory not empty
rm: Backups.backupdb/MacBook/Latest/MacBook/somedir/somefile: Operation not permitted
Il existe un certain nombre de raisons pour lesquelles je ne souhaite pas utiliser l'interface graphique de Time Machine ni le Finder à cet effet. Si possible, j'aimerais pouvoir maintenir la protection étendue pour tous les autres fichiers (j'aimerais ne pas les désactiver globalement, à moins que je ne puisse le réactiver une fois mon travail terminé).
Pour contourner les erreurs "opération non autorisée", utilisez le programme Time Machine Safety Net : "contournement":
Sudo /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass rm -rfv /Volumes/[disk]/Backups.backupdb/[path]
Dans 10.8 Mountain Lion, contournement déplacé dans 'Helpers':
/System/Library/Extensions/TMSafetyNet.kext/Helpers/bypass
Dans 10h10 Yosemite, le contournement s'est déplacé ici:
/System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass
Attention lorsque vous l'utilisez pour supprimer des instantanés spécifiques: comme Time Machine utilise des liens physiques, l'utilisation de rm -r
sur des dossiers peut également affecter les instantanés anciens et plus récents du même machine . (Voir les autres réponses faisant référence à tmutil delete
pour supprimer en toute sécurité un instantané spécifique.) Utiliser rm
pour supprimer tous les instantanés d'un seul ordinateur est cependant correct. Ainsi, utilisez rm
pour supprimer un fichier spécifique, qui ne supprimera que le fichier lié de manière instantanée du ou des instantanés que vous spécifiez, en supposant que le fichier ne se trouve pas dans un répertoire lié en dur, car vous supprimeriez alors le fichier de tous ces répertoires liés en dur.
BLUF (ligne du bas à l'avant):
Sudo tmutil delete snapshot-dir
L'utilisation de Sudo chmod -R -N folder
pour supprimer toutes les listes de contrôle d'accès d'une hiérarchie de dossiers ne fonctionne pas sur les fichiers et les dossiers dans Backups.backupdbde Time Machine, à cause de le mécanismeTM Safety Netet les critères décrits dans ce 318 Journal technique post (mais éventuellement pas exactement comme décrit).
(Avant d’apprendre cela en consultant le filet de sécurité mentionné dans la réponse d’Eric W (qui fonctionne), je n’avais testé que sur un dossier cloné à partir d’un sous-dossier d’une sauvegarde TM, et il y avait chmod , mais essayer chmod sur un dossier d’une sauvegarde TM réelle donne l’erreur "Opération non autorisée".)
D'utilisation possible:
Sous Mac OS 10.7+, il existe un tmutil (que je n'ai pas encore essayé, car je suis toujours sur Snow Leopard). Il a un verbedeletequi, selon la description "peut supprimer des instantanés de sauvegardes qui n'ont pas été effectuées ou réclamés par le machine " (où un" instantané " est un dossier daté représentant une sauvegarde incrémentielle unique). Cela ne me dit pas si cela signifie que il ne peut pas supprimer les instantanés qui sont créés ou revendiqués par la machine actuelle. )
Avertissement concernant l’utilisation de la commande bypass
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 tout fichier de /2014-11-06/folder/
convient et n’affecte que la sauvegarde pour cette date. Le nombre de références de liaison physique est réduit, de sorte que " inode " pour file2
sera supprimé, mais les inodes pour file1
et file3
auront toujours un nombre de références égal à 1 en raison des sauvegardes ultérieures. Par conséquent, rm -R /2014-11-06
convient également.
Cependant, supprimer tout fichier de /2014-11-13/folder/
, /2014-11-20/folder/
ou /2014-11-27/folder/
le supprimera effectivement de ces 3 dossiers.
Le problème est que rm -R
ne se soucie pas des dossiers liés en dur. Il revient simplement dans n'importe quel dossier dur lié qu'il trouve, supprime 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 lié en 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 rm -R
, utilisez tmutil delete
comme expliqué dans la réponse d'Arne .
En passant, il semble que la commande unlink
sous 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 des dossiers liés de la même manière que GNU Coreutils , comme ceux installés 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 TopSites.plist
a été modifié pour la dernière fois le 2014-11-06 et lié en dur le 2014-11-13, certains autres fichiers ayant alors été ajoutés, modifiés ou supprimés dans le dossier Safari
. Ensuite, le contenu du dossier Safari
n'a pas changé dans les deux sauvegardes suivantes. Ainsi, les 2014-11-20 et 2014-11-27, 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//
Remarque: en raison du "filet de sécurité TM" mentionné par Eric W, cette réponse ne fonctionne pas dans le cas d'une sauvegarde Time Machine, à laquelle la question se rapporte spécifiquement. Mais dans presque tous les autres cas, les informations sur la façon de se débarrasser des listes de contrôle d'accès sont pertinentes.
Il n'est pas nécessaire d'utiliser des outils ACL copiés à partir d'un ancien système d'exploitation.
Utilisez ls -le
pour afficher les ACL et chmod
pour les modifier.
Pour plus d'informations, tapez man chmod
et reportez-vous à la section "Options de manipulation ACL".
La commande permettant de supprimer toutes les listes de contrôle d'accès d'une hiérarchie de dossiers est la suivante:
chmod -R -N foldername
Time Machine fonctionne comme rshapshot. Il crée une arborescence de liens durs pour chaque nouvelle sauvegarde. Les liens physiques vers des fichiers existants dans une sauvegarde précédente utilisent très peu d'espace supplémentaire. Ce n'est que lorsque le dernier lien dur vers un fichier est supprimé que le fichier est réellement supprimé du système de fichiers.
Supprimer une sauvegarde individuelle entière ne fera pas de mal. Vous ne faites que supprimer les liens durs. Aucune autre sauvegarde ne sera affectée. Mais cela peut être accompli via tmutil.
Un scénario dans lequel il peut être nécessaire de contourner la protection consiste à supprimer un fichier spécifique de toutes les sauvegardes (et la raison pour laquelle je me suis retrouvé dans ce post).
Mon disque de sauvegarde est plein. J'ai un très gros fichier (plusieurs giga-octets) qui a été sauvegardé pendant des mois. Il existe une copie physique de celle-ci, mais de nombreux instantanés avec des liens en dur vers cette copie. Pour réellement supprimer ce fichier, je dois supprimer le lien physique de chaque sauvegarde.
Notez que le numéro d'inode est le même pour tous les liens physiques vers le même fichier.
% cd /Volumes/WD\ 500G\ USB/Backups.backupdb/csm-laptop
% ls -li */Macintosh\ HD/Users/csm/vm.img
...
2740350 -rw-r--r--@ 28 csm staff 42949672960 Feb 17 16:12 2015-05-08-005636/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm staff 42949672960 Feb 17 16:12 2015-05-08-015812/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm staff 42949672960 Feb 17 16:12 2015-05-08-030036/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm staff 42949672960 Feb 17 16:12 2015-05-08-041307/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm staff 42949672960 Feb 17 16:12 Latest/Macintosh HD/Users/csm/vm.img
(Dernier est juste un lien symbolique vers le dernier répertoire daté)
% Sudo bypass rm -f */Macintosh\ HD\Users\csm\vm.img
Le fichier est supprimé de toutes les sauvegardes et de l'espace est retourné. Si le fichier a changé au fil du temps, chaque copie de sauvegarde aura une copie complète et l'espace retourné sera énorme.
Si vous n'exécutez pas la commande en tant qu'utilisateur "propriétaire" de la sauvegarde, vous aurez du mal à supprimer de la ligne de commande. Je venais d'avoir ce problème avec une migration, et nous devions idem la sauvegarde complète de Time Machine (1 To +) et formater le disque avant de pouvoir obtenir un accès quelconque - et croyez-moi, j'ai tout essayé pour outrepasser les autorisations.
Vous pouvez faire ls
lister les attributs étendus dans une vue longue en utilisant l'indicateur -@
. Il liste les ACL lorsque vous fournissez l'indicateur -e
. Donc, vous pouvez trouver ce que vous avez à faire en utilisant ls -lea@ DIR
.
À en juger par mes sauvegardes Time Machine locales, il semble que Time Machine applique les attributs étendus avec des métadonnées sur les instantanés les plus récents et les plus anciens. Les données stockées par les xattrs ressemblent à des plist binaires. Celles-ci semblent anodines.
Time Machine cherche également à appliquer des listes de contrôle d'accès à certains répertoires connus, tels que ceux placés dans un répertoire utilisateur standard. Deux types d’ACL se dressent potentiellement sur votre chemin: ceux qui s’appliquent directement au fichier ou au répertoire qui refuse la suppression et ceux qui s’appliquent à un parent du fichier qui refusent delete_child.
Malheureusement, Mac OS X ne fournit pas les utilitaires utilisateur getfacl
et setfacl
spécifiés par POSIX.2c pour afficher et manipuler les ACL. Pour jouer avec les ACL, vous devrez faire de la programmation; voir la page de manuel acl(3)
.
Si vous souhaitez supprimer tous les fichiers d'un dossier et pas seulement des fichiers spécifiques, vous pouvez le faire en ajoutant le dossier à la liste d'exclusion de Time Machine. (Préférences système -> Time Machine -> Options. Faites glisser le dossier ici.)
La prochaine fois que vous effectuerez une sauvegarde, des copies de ce dossier seront supprimées des sauvegardes précédentes.
Maintenant, si vous voulez vraiment faire cela à partir d'une interface de ligne de commande, il existe un moyen, quoique un peu fastidieux.
plutil -convert xml1 com.Apple.TimeMachine.plist
<string>/Path/To/Exclude</string>
plutil -convert binary1 com.Apple.TimeMachine.plist
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper -auto
Modifier: Lorsque vous effectuez l'étape 9, toutes les copies du dossier nouvellement exclu seront effacées des sauvegardes précédentes.
Pour supprimer l'exception, copiez votre sauvegarde dans/Library/Preferences.