O comando Renomear pareceu remover vários arquivos. Posso recuperá-los?

Considere o comando que você executou:

rename 's/\.zip$/\.cbz/' *.zip

Isso altera os últimos quatro caracteres de cada nome de arquivo ou diretório ^* que corresponde ao padrão glob *.zipno diretório atual de .zippara .cbz. Isso é tudo. Ele usa uma expressão de substituição Perl para realizar essa renomeação.

Além disso, pelo menos no meu sistema, renamerecusarei renomear um item (arquivo) onde o nome de destino já exista:

touch a.zip a.zap
rename 's/\.zip$/.zap/' *.zip
a.zip not renamed: a.zap already exists

Descobri que cerca de 2/3 dos meus arquivos estavam faltando depois

Não consigo ver nada ⁺ razoável no cenário que você descreveu que faria com que arquivos (ou diretórios, etc.) desaparecessem. Talvez houvesse outro comando como mv, que não executa verificações de integridade antes de substituir. Verifique o seu historypara ver o que isso mostra a você

^{* Na verdade, ele renomeará qualquer tipo de item, seja arquivo normal, diretório, dispositivo, canal... mas somente onde corresponder aos critérios que descrevi}

^{+ Arquivos que começam com um travessão ( -) ou travessão duplo ( --) são sempre problemáticos. Aqui também, a menos que você proteja seus padrões de arquivo separando argumentos de comando e argumentos de arquivo com um formato autônomo --ou usando um ./nameformato modificado em vez de simples name. Por exemplo, mv -- -a dashapara renomear -apara dash.}

$ touch {comic5,{a..d}}.zip './--e=BEGIN{unlink for <c*>}#.zip'
$ ls
 a.zip   b.zip   comic5.zip   c.zip   d.zip  '--e=BEGIN{unlink for <c*>}#.zip'

$ rename 's/\.zip$/\.cbz/' *.zip
$ ls
 a.zip   b.zip   d.zip  '--e=BEGIN{unlink for <c*>}#.zip'

Ops! Todos os arquivos cujo nome começa com cforam removidos.

Para a File::Renameimplementação do rename, esse tipo de problema foi corrigido em 1.99 (a meu pedido), mas o Ubuntu 22.04 vem com a versão 1.30.

Aqui, você desejaria:

rename 's/\.zip\z/\.cbz/' ./*.zip

Com esse ./prefixo evitando que qualquer nome de arquivo zip seja considerado uma opção por rename¹.

Ou, com essa implementação específica de rename, passe a lista de arquivos por meio de sua entrada padrão em vez de argumentos:

printf '%s\0' *.zip | rename -0 's/\.zip/\.cbz/'

Que com shells onde printfestá embutido (a maioria) também funciona em torno do Argument list too longlimite.

Ou use zsh's zmvque não apresenta esse tipo de problema, possui algumas proteções extras e geralmente é mais fácil de usar²:

autoload -Uz zmv
zmv '(*).zip' '$1.cbz'

Agora, é improvável que esse tipo de coisa aconteça por acaso. Se foi isso que aconteceu, alguém teria plantado um arquivo malicioso com nome semelhante no diretório atual, sabendo que você executaria tal comando.

Se o código malicioso o fez unlink()ou se os arquivos foram removidos como resultado de uma rename()substituição do arquivo, você pode ter alguma sorte usando alguma abordagem de recuperação/recuperação do sistema de arquivos . Se ele fizesse o equivalente ao que shred/ wipefaz ou criptografasse o conteúdo antes de mover os arquivos para outro lugar, como faria o ransomware, sua melhor opção seria restaurar a partir do backup.

Na ausência de nomes de arquivos maliciosos, renamenormalmente não deve perder dados, pois verifica se o arquivo de destino existe antes de renomeá-lo. Você pode perder arquivos de links simbólicos se o alvo desses links simbólicos não estiver acessível como renameuso-e <the-target> e isso retornaria falso para um link simbólico que não resolve como para -eo [utilitário:

$ touch a.zip
$ ln -s /x a.bcz
$ ls -n
total 4
lrwxrwxrwx 1 1000 1000 2 Dec 22 08:39 a.bcz -> /x
-rw-r--r-- 1 1000 1000 0 Dec 22 08:39 a.zip

$ rename -v 's/\.zip$/\.bcz/' *.zip
a.zip renamed as a.bcz
$ ls -n
total 0
-rw-r--r-- 1 1000 1000 0 Dec 22 08:39 a.bcz

Ops! Esse a.bczlink simbólico (quebrado) desapareceu.

Mas os links simbólicos ocupam muito pouco espaço no disco, então isso não poderia explicar a perda de 80 dos 120 GiB que você sofreu.

Assim como Chris, suspeito que seu problema estava em outro lugar. Seus arquivos podem ainda estar lá, mas não no diretório que você acha que deveriam estar. Experimente umsudo find / -iname 'comic5.zip' -o -iname 'comic5.cbz'

^{¹ Observe também o \zlocal $que você geralmente deseja usar em regexps que correspondem a outras coisas além de linhas , como $correspondências no final do assunto (que você deseja aqui) ou antes de um caractere de nova linha no final do assunto (que você deseja não quero, neste caso específico, o assunto termina em .zipe não em nova linha, então isso não seria um problema).}

^{² mesmo que geralmente seja mais lento, pois chama um mvpor arquivo. Embora você possa executar zmodload zsh/filespara obter um arquivo mv.}