Una advertencia sobre el uso del bypass
comando para eliminar una copia de seguridad anterior: si la copia de seguridad eliminada tiene carpetas que son exactamente iguales en copias de seguridad anteriores o posteriores, ¡entonces los archivos también pueden eliminarse de copias de seguridad anteriores o posteriores !
Time Machine no solo usa enlaces duros para archivos sin cambios, sino que también usa enlaces duros para carpetas en las que no se agregaron, cambiaron ni eliminaron archivos. Esto resulta en algo como:
/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/
Con lo anterior, eliminar cualquier archivo /2014-11-06/folder/
está bien y solo afecta la copia de seguridad para esa fecha. Los recuentos de referencia del enlace rígido se reducen, por lo que se eliminará el " inodo " para file2
, pero los inodos para file1
y file3
todavía tendrán un recuento de referencia de 1 debido a las copias de seguridad posteriores. Por lo tanto, también rm -R /2014-11-06
está bien.
Sin embargo, eliminar cualquier archivo de cualquiera de ellos /2014-11-13/folder/
, /2014-11-20/folder/
o /2014-11-27/folder/
lo eliminará efectivamente de todas esas 3 carpetas.
El problema es que rm -R
no le importan las carpetas vinculadas. Simplemente vuelve a aparecer en cualquier carpeta vinculada que encuentre, elimina audazmente todos sus archivos y luego elimina la carpeta vacía.
Por lo tanto: al eliminar una copia de seguridad anterior, una no debe repetirse en una carpeta vinculada y eliminar su contenido. En cambio, uno solo debe eliminar el enlace duro para la carpeta en sí . Entonces, en lugar de rm -R
usar tmutil delete
como se explica en la respuesta de Arne .
Por otro lado, parece que el unlink
comando OS X no se puede usar en carpetas : "solo se puede proporcionar un argumento, que no debe ser un directorio" . La API de OS X puede eliminar carpetas vinculadas, al igual que GNU Coreutils , como las instaladas con Homebrew .
Finalmente, para probar todo lo anterior, un caso de prueba (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
Tenga en cuenta que el número de enlaces para cada aparición es 2 (segunda columna). Eliminemos la primera aparición:
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
Entonces, después de desvincular uno de los archivos, el número de enlaces se redujo a 1 para cada aparición, aunque el archivo todavía se muestra 3 veces. No hay problemas todavía. Elimine la primera aparición nuevamente:
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
Ahora todos se han ido. Aparentemente, el archivo TopSites.plist
se modificó por última vez el 2014-11-06 y se vinculó el 2014-11-13, ya que luego se agregaron, cambiaron o eliminaron otros archivos en la Safari
carpeta. A continuación, el contenido de la Safari
carpeta no cambió en las dos copias de seguridad posteriores, por lo que el 20 de noviembre de 2014 y el 27 de noviembre de 2014 la Safari
carpeta estaba vinculada a la copia de seguridad anterior.
De hecho, las 4 carpetas solo usan 2 inodes (primera columna):
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//