Hice una copia de seguridad de un directorio con algunos directorios dentro, usando rsync -aPv source/ dest. No generó mensajes de error, ni devolvió un estado de falla y avanzó hasta el final. Copió todos los archivos de source, desto eso creo.
El problema es que sólo los archivos de la raíz del directorio de origen se copiaron correctamente y se pueden abrir y utilizar. El resto de los archivos y directorios se han corrompido de alguna manera y se producen errores:
~/Pictures $ cd Screenshots/
cd: Permission denied: “Screenshots/”
~/Pictures $ ls -l Screenshots/
ls: cannot access 'Screenshots/2016-05-02-23:11:15.png': Permission denied
ls: cannot access 'Screenshots/2015-08-07-17-26-33.png': Permission denied
ls: cannot access 'Screenshots/screenshot_2019-05-27_20-41-55_665836194.png': Permission denied
ls: cannot access 'Screenshots/screenshot_2019-05-05_23-17-16_571047883.png': Permission denied
...
total 0
-????????? ? ? ? ? ? 2015-03-22-03-49-39.png
-????????? ? ? ? ? ? 2015-04-03-20-17-31.png
-????????? ? ? ? ? ? 2015-05-18-22-09-39.png
-????????? ? ? ? ? ? 2015-08-07-17-26-33.png
...
Puedo acceder a esos directorios usando ciertos administradores de archivos (probé PCManFM; Ranger no funcionó) y revela que los archivos están dañados y no se pueden abrir con los programas predeterminados designados (por ejemplo, qimgv para imágenes, mpv para videos).
No estoy seguro de si este problema ha dañado los archivos o solo los directorios, de manera que no se puede acceder al contenido real, pero tal vez todavía esté allí, o tal vez los metadatos estén dañados (en su mayoría son archivos JPG y PNG). ¿Cómo puedo recuperar el acceso a esos archivos y su contenido?
Respuesta1
El resultado es exactamente igual al que obtiene si intenta enumerar un directorio cuyos xbits de permiso faltan.
A continuación se muestra un ejemplo de cómo reproducir la situación:
$ cd /tmp
$ mkdir dirperms
$ cd dirperms
$ touch foo bar baz
$ mkdir zot
$ cd ..
$ chmod a-x dirperms
$ cd dirperms
bash: cd: dirperms: Permission denied
$ ls -l dirperms
ls: cannot access 'dirperms/baz': Permission denied
ls: cannot access 'dirperms/bar': Permission denied
ls: cannot access 'dirperms/foo': Permission denied
ls: cannot access 'dirperms/zot': Permission denied
total 0
-????????? ? ? ? ? ? bar
-????????? ? ? ? ? ? baz
-????????? ? ? ? ? ? foo
d????????? ? ? ? ? ? zot/
Entonces, usar testdiskprobablemente fue excesivo; simplemente podrías haber arreglado los permisos del Screenshotsdirectorio con un archivo chmod -R u+X Screenshots.
La causa principal de los permisos erróneos podría ser que el sistema de archivos fuente original era quizás un sistema de archivos que no admitía permisos de estilo Unix y, por lo tanto, los permisos informados por el controlador del sistema de archivos (en aras de la compatibilidad con POSIX) no coincidían con la realidad de lo que el conductor realmente permitió rsyncel acceso. Entonces rsyncreplicó los permisos falsos en el sistema de archivos de destino, donde en realidad se usaron como configuraciones de permisos reales, causando así el problema.