Ostrzeżenie o użyciu bypasspolecenia do usunięcia starej kopii zapasowej: jeśli usunięta kopia zapasowa zawiera foldery, które są dokładnie takie same we wcześniejszych lub późniejszych kopiach zapasowych, wówczas pliki mogą zostać usunięte również z wcześniejszych lub późniejszych kopii zapasowych !
Time Machine nie tylko używa twardych linków do niezmienionych plików, ale także używa twardych linków do folderów, w których żadne pliki nie zostały dodane, zmienione lub w ogóle usunięte. Powoduje to coś takiego:
/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/
W związku z powyższym usunięcie dowolnego pliku /2014-11-06/folder/jest prawidłowe i wpływa tylko na kopię zapasową dla tej daty. Liczba odwołań do twardego łącza jest zmniejszona, więc „i- węzeł ” dla file2zostanie usunięty, ale dla file1i- węzłów liczba odniesień i file3nadal będzie wynosić 1 z powodu późniejszych kopii zapasowych. Dlatego też rm -R /2014-11-06jest w porządku.
Jednak usunięcie dowolnego pliku z albo /2014-11-13/folder/, /2014-11-20/folder/albo /2014-11-27/folder/skutecznie usunąć go ze wszystkich tych 3 folderach.
Problem polega na tym, rm -Rże nie dba o foldery na stałe. Po prostu rekursuje w dowolnym znalezionym folderze, odważnie usuwa wszystkie swoje pliki, a następnie usuwa pusty folder.
Tak więc: usuwając starą kopię zapasową, nie należy ponownie zapisywać jej w folderze połączonym na stałe i usuwać jej zawartość. Zamiast tego należy usunąć tylko twardy link do samego folderu . Więc zamiast rm -Rużywać, tmutil deletejak wyjaśniono w odpowiedzi Arne .
Tak na marginesie, wydaje się, że OS X unlinkkomenda nie może być stosowany na foldery : „tylko jeden argument, który nie może być katalogiem, mogą być dostarczane” . Interfejs API OS X może usuwać foldery na stałe , podobnie jak GNU Coreutils , na przykład instalowane przy użyciu Homebrew .
Wreszcie, aby udowodnić wszystkie powyższe, przypadek testowy (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
Zauważ, że liczba linków dla każdego wystąpienia wynosi 2 (druga kolumna). Usuńmy pierwsze wystąpienie:
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
Po odłączeniu jednego z plików liczba łączy spadła do 1 dla każdego wystąpienia, chociaż plik jest nadal wyświetlany 3 razy. Jeszcze żadnych problemów. Usuń pierwsze wystąpienie ponownie:
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
Teraz wszystko zniknęło. Najwyraźniej plik TopSites.plistzostał ostatnio zmieniony 2014-11-06 i połączony na twardo w dniu 13.11.2014, ponieważ niektóre inne pliki zostały dodane, zmienione lub usunięte w Safarifolderze. Następnie zawartość Safarifolderu nie zmieniła się w dwóch kolejnych kopiach zapasowych, więc w dniach 2014-11-20 i 2014-11-27 Safarifolder został na stałe połączony z poprzednią kopią zapasową.
Rzeczywiście, 4 foldery używają tylko 2 i-węzłów (pierwsza kolumna):
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//