Fiz um backup de um diretório com alguns diretórios dentro, usando rsync -aPv source/ dest. Ele não gerou mensagens de erro, nem retornou um status de falha e progrediu até o fim. Ele copiou todos os arquivos para sourcedentro dest, ou assim pensei.
O problema é que apenas os arquivos da raiz do diretório de origem foram copiados corretamente e podem ser abertos e usados. O restante dos arquivos e diretórios foram corrompidos de alguma forma e ocorrem erros:
~/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
...
Posso acessar esses diretórios usando determinados gerenciadores de arquivos (tentei o PCManFM; o ranger não funcionou) e isso revela que os arquivos estão corrompidos e não podem ser abertos com programas padrão designados (por exemplo, qimgv para imagens, mpv para vídeos).
Não tenho certeza se esse problema corrompeu os arquivos ou apenas os diretórios, de uma forma que o conteúdo real não está acessível, mas talvez ainda esteja lá, ou talvez os metadados estejam corrompidos (principalmente arquivos JPG e PNG). Como posso recuperar o acesso a esses arquivos e seu conteúdo?
Responder1
A saída é exatamente igual à que você obtém se tentar listar um diretório cujos xbits de permissão estão faltando.
Aqui está um exemplo de como reproduzir a situação:
$ 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/
Então, usar testdiskprovavelmente foi um exagero; você poderia simplesmente ter corrigido as permissões do Screenshotsdiretório com um arquivo chmod -R u+X Screenshots.
A causa raiz das permissões erradas pode ser que o sistema de arquivos de origem original talvez fosse um sistema de arquivos que não suportava permissões no estilo Unix e, portanto, as permissões relatadas pelo driver do sistema de arquivos (por uma questão de compatibilidade POSIX) não correspondiam à realidade do que o driver realmente permitiu rsynco acesso. Então rsyncreplicou as permissões falsas para o sistema de arquivos de destino, onde elas foram realmente usadas como configurações de permissão reais, causando assim o problema.