Os erros do rsync 'não podem excluir o diretório não vazio', mesmo com a opção --force

28

Ao executar este comando:

$ sudo rsync -r --delete --force --checksum --exclude=uploads /data/prep/* /data/app/

Estou recebendo a seguinte saída:

cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source
cannot delete non-empty directory: html/js/ckeditor/_samples
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor

Ao ler o man rsync, fiquei com a impressão de que a --forceopção instruiria o rsync a excluir esses diretórios não vazios, que é o resultado desejado.

Ref:

--force                 force deletion of dirs even if not empty

Como posso modificar o comando para excluir os diretórios não vazios?

Estou usando o rsync versão 3.0.8, no Gentoo Base System versão 2.0.3, caso isso seja relevante.

Atualização: adicionado sudoao comando para deixar claro que este não é um problema de permissão de arquivo.

— tommarshall
fonte

Qual sistema de arquivos é o destino? O sistema de arquivos precisa de reparo?

— Marcus Downing

O sistema de arquivos é ext3. É possível que o sistema de arquivos esteja precisando ou seja reparado. Vou fsckna próxima oportunidade e atualizar com os resultados.

— tommarshall

Acabei fsckde encontrar o sistema e esse problema ainda está presente.

— precisa saber é o seguinte

39

Você tentou adicionar --delete-excluded?

Se você excluir um diretório nas pastas excluídas no lado "remoto", rsync --deletenão excluirá a pasta excluída no site "local".

— Martin Höger
fonte

Havia uma pasta chamada uploadsnos diretórios html/js/ckeditor/_source/plugins/uicolor/yui, html/js/ckeditor/_samplese html/js/ckeditor/plugins/uicolor/yui. Obrigado pela ajuda.

— 214146 Tommarshall

se estiver usando, --delete-excludedmas você ainda deseja excluir certos arquivos / diretórios da exclusão, é possível colocar esses arquivos / diretórios --filter 'protect some_dir/', por exemplo:rsync -ac --delete --delete-excluded --exclude '*.html' --filter 'protect .git/' . /target/destination/

— alexandre1985

6

Aqui estão as fontes possíveis desse problema:

(1) Este erro pode ser o resultado da opção -b (--backup). Essa opção criará um backup de cada arquivo excluído, acrescentando um til ( ~ ) ao nome do arquivo. (Isso me confundiu, pois o nome do arquivo é claramente um backup, mas o nome do diretório não é, pois você não pode ver o til.)

Para verificar se esse é o mesmo caso, leia o diretório de destino no nível mais profundo e verifique se há algum arquivo final de til (~). Observe que esses nomes de arquivos anexados a til são então invisíveis em algum sistema comum de navegação de arquivos, portanto, você pode não vê-los.

Para resolver esse caso, prefira a opção --backup-dir = DIR, por exemplo --backup-dir = .rsync_bak.

(2) A opção --exclude pode ter os mesmos resultados. O que possivelmente está acontecendo no seu caso. O sistema de padrões é poderoso, mas pode ser enganoso. Por exemplo, se você escrever --exclude = '* ~', isso ignorará todos os arquivos de finalização de til, resultando exatamente como no caso (1) acima.

da página de manual do rsync:

se o padrão começar com um /, ele será ancorado em um ponto específico na hierarquia de arquivos; caso contrário, será comparado com o final do nome do caminho

Se você escrever --exclude = uploads, isso excluirá todos os arquivos denominados "updloads", em qualquer nível da sua árvore de arquivos.

Verifique se há um arquivo chamado "uploads" dentro de seus diretórios incapazes de excluir.

A solução seria alterar "--exclude = uploads" para "--exclude = uploads /"

— user3586623
fonte

0

Na minha configuração ((fonte é o formato Ubuntu, tipo ext4, para direcionar o tipo Western Digital fuseblk), ele trabalha com:

rsync -a -v --progress --modify-window=1 -c -b -i -s -m --del -vv --ignore-errors --chmod=ugo=rwx --delete --delete-excluded  --exclude='*~'  --exclude='.*' --backup-dir=.rsync_bak /home/test /media/user/usbHDD

— Em lei
fonte

2

Qual parte disso realmente resolve o problema?

— Michael Hampton

0

Use regras em arquivos de filtro em vez de --exclude. Isso permite que você marque as exclusões como "persizáveis", o que permitirá excluir diretórios não vazios que contêm arquivos excluídos.

Veja esta resposta para detalhes.

— mivk
fonte

-1

Um diretório precisa estar vazio para que você possa excluí-lo; o sistema de arquivos normalmente exige isso.

Portanto, normalmente rsyncou rmexcluiria recursivamente todo o conteúdo primeiro e somente depois o diretório agora vazio.

Se o usuário atual não for o proprietário de todos os arquivos, as permissões do sistema de arquivos não permitirão excluir esses arquivos. Como eles não serão removidos, o diretório não será esvaziado e a exclusão falhará.

Meu primeiro palpite seria que alguns arquivos desse diretório sejam de propriedade de outro usuário, por exemplo, o apache ou de ninguém.

— HBruijn
fonte

Obrigado. Os arquivos nos diretórios são de fato propriedade de um usuário dentro do grupo apache, no entanto, apenas tentei executar este comando como esse usuário e obtive os mesmos erros.

— tommarshall

Além disso, se fosse um problema de permissão de arquivo, eu esperaria executar o mesmo comando do 'sudo' para resolver o problema, mas esse não é o caso. No entanto, corrija-me se estiver enganado.

— tommarshall

1

A execução do comando como root deve superar a maioria dos problemas de permissão, sim. (o local provável onde isso ainda falharia é em uma montagem nfs para nomear um, um arquivo imutável outro). Uma verificação simples ls -lapara ver por que o diretório ainda não está vazio. lsattrexibirá arquivos imutáveis.

— HBruijn

Obrigado pelas informações adicionais, no entanto, a lsattrpartir de um dos diretórios listados gera o seguinte: --------------- ./assets(sem sinalizador i) e o arquivo não está em uma montagem nfs. Existem outras razões pelas quais você poderia pensar por que o comando ainda falharia com o sudo?

— tommarshall

Existem links simbólicos ou apenas arquivos reais?

— Marcus Downing