Предупреждение об использовании 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/
в порядке, и влияет только на резервную копию на эту дату. Жесткие подсчет ссылки уменьшаются, так что « индексный дескриптор » для file2
будет удален, но дескрипторы для 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
как объяснено в ответе Арне .
Как и в сторону, кажется , что OS X unlink
команда не может быть использована в папках : «только один аргумент, который не должен быть каталогом, могут быть поставлены» . 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//