Предупреждение об использовании команды bypass для удаления старой резервной копии: если в удаленной резервной копии есть папки, которые в точности совпадают с более ранними или более поздними резервными копиями, файлы могут быть также удалены из более ранних или более поздних резервных копий !
Time Machine не только использует жесткие ссылки для неизмененных файлов, но также использует жесткие ссылки для папок, в которых файлы не были добавлены, изменены или удалены вообще. Это приводит к чему-то вроде:
/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/
С учетом вышеизложенного удаление любого файла из /2014-11-06/folder/ , и влияет только на резервную копию на эту дату. Количество ссылок жестких ссылок уменьшается, поэтому « inode » для file2 будет удален, но inode для file1 и file3 будет по-прежнему иметь счетчик ссылок 1 из-за более позднего резервного копирования. Следовательно, rm -R /2014-11-06 тоже подойдет .
Однако удаление любого файла из /2014-11-13/folder/ , /2014-11-20/folder/ или /2014-11-27/folder/ эффективно удалит его из всех этих 3 папок.
Проблема в том, что rm -R не заботится о жестко связанных папках. Он просто возвращается в любую жестко связанную папку, которую находит, смело удаляет все свои файлы, а затем удаляет пустую папку.
Итак: при удалении старой резервной копии не следует возвращаться в жестко связанную папку и удалять ее содержимое.Вместо этого следует удалить только жесткую ссылку для самой папки. Поэтому вместо rm -R используйте tmutil delete как объяснено в ответе Арне.
Кроме того, кажется, что команда unlink OS X не может использоваться для папок: «может быть предоставлен только один аргумент, который не должен быть каталогом». API OS X может удалять жестко связанные папки, как и GNU Coreutils, например, установленный с помощью Homebrew.
Наконец, чтобы доказать все вышесказанное, тестовый пример (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
Обратите внимание, что количество ссылок для каждого экземпляра равно 2 (второй столбец). Давайте удалим первое вхождение:
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
Таким образом, после отсоединения одного из файлов количество ссылок уменьшилось до 1 для каждого вхождения, хотя файл по-прежнему отображается 3 раза. Проблем пока нет. Удалите первое вхождение снова:
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
Теперь все прошло. Очевидно, файл TopSites.plist был последний раз изменен 2014-11-06 и жестко связан с 2014-11-13, а затем некоторые другие файлы были добавлены, изменены или удалены в папке Safari . Затем содержимое папки Safari не изменилось в последующих двух резервных копиях, поэтому в 2014-11-20 и 2014-11-27 папка Safari была жестко связана с предыдущей резервной копией.
Действительно, 4 папки используют только 2 inode (первый столбец):
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//
