Aws-cli: aws s3 sync não sincroniza a estrutura da pasta s3 localmente

Esse comportamento é conhecido. A razão pela qual o comando sync se comporta dessa maneira é que s3 não usa diretórios fisicamente. Existem apenas baldes e objetos. Os objetos têm prefixos que agem como diretórios, mas s3 não designa um objeto físico específico para ser um diretório.

Portanto, quando a sincronização ocorre, apenas os arquivos são transferidos para s3 porque s3 não tem diretórios físicos. Portanto, quando você tenta sincronizar diretórios vazios, nada é carregado porque não há arquivos neles. Depois de colocar os itens no diretório, o arquivo (com o prefixo que representa o diretório) será carregado.

Obrigado Kyle, está claro. Eu sei como o S3 armazena arquivos, mas às vezes precisamos da mesma estrutura de diretório em vários lugares, mesmo se houver alguns vazios, ou remover se não precisarmos mais.
Um bom exemplo se você tiver uma estrutura de diretório complexa com muito conteúdo local do que sincronizou com o S3. Depois disso, um mecanismo automatizado sincroniza essa estrutura periodicamente para várias instâncias em execução. Você mantém atualizado (apaga) a maior parte do conteúdo do S3 e, em seguida, o automatismo sincroniza novamente com os locais que você usou antes. Infelizmente, você descobrirá que a complexa estrutura de diretório original permanece para sempre em alvos de sincronização, o que pode causar confusão se você quiser verificá-la ou se seu programa tentar usar essas pastas vazias porque você precisa sempre da mesma em todos os lugares. Além disso, as pessoas que o usam com as opções --delete talvez usem o equivalente "rsync" antes no Linux, que mantém as pastas sincronizadas, então conta com a mesma operação.
Acho que não seria difícil implementar uma chave ou opção para a ferramenta aws para detectar de alguma forma se um objeto S3 é um arquivo ou pasta (lista, tamanho, etc.) e criar / excluí-los localmente ou em um balde S3 (por exemplo list (bucket.list ("", "/"))?

Isso faz sentido. Analisará como adicionar um recurso para ele.

Isso seria muito útil para a nossa situação também. Se fosse adicionado como uma opção (--sync-empty-directory), as pessoas poderiam escolher usá-lo quando necessário.

1 Preciso muito desse recurso

+1. Gostaria de usar.

+1

Também fiquei surpreso com esse comportamento, já que se chama "sync".
Posso contornar isso em meu caso de uso específico, mas os futuros usuários podem ser poupados do sofrimento :)

1 sobre ser capaz de sincronizar a estrutura do diretório! Se você excluir uma pasta, isso apenas removerá o conteúdo, mas deixará a pasta para trás ...

+1. Eu tenho as mesmas necessidades.

+1 - surpreso que ainda não foi implementado. Claro, no meu caso não importa muito e posso contornar isso (ou apenas usar arquivos de espaço reservado ao criar estruturas), mas seria uma vantagem apenas ter suporte para s3 sync ou s3 cp.

+1

s3cmd sync mantém a estrutura de pastas, mas, portanto, tem alguns problemas ao conceder acesso durante a sincronização, então é necessário executar outro s3cmd setacl --recursive depois ...

+1

+1

+1

Obrigado pelo feedback a todos. Acho que a melhor opção que vi é adicionar uma opção --sync-empty-directories . Vamos fazer isso.

@jamesls Estou esperando funcionalidades parecidas com o rsync, mas o s3 como um armazenamento de objeto definitivamente não é o mesmo.

+1

+1

Qualquer cronograma para este recurso?

Como solução temporária, adicionei um arquivo .s3keep vazio aos diretórios vazios e funcionou para mim. Este é um hack que costumo usar para enganar o git a não tratar diretórios vazios como vazios :)

Isso também permitirá "remover / excluir" diretórios vazios no S3?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

_Faz muito sentido durante as migrações de dados para s3._

+1

1 Acabei de ser esmagado por isso ... Arg ....

+1

+10
É possível contornar isso com arquivos fictícios, mas seria mais limpo se houvesse uma opção para forçar a sincronização de um prefixo vazio.

+1. Caso de uso: backup de um repositório svn.

De forma geral:
coisa de sincronização aws s3
aws s3 syncthing_copy

Eu esperava que thing_copy fosse exatamente igual a thing.

+1

+1

+1

+1 precisa deletar diretórios vazios

Como está o andamento da adição desta opção --sync-empty-directories ?
algum feedback da equipe AWS?
Obrigado.

+1 seria um recurso muito útil para uma ferramenta muito útil

+1

+1 (eu também gostaria que este recurso fosse implementado e gostaria que Github.com tivesse uma interface semelhante ao StackOverflow.com para "votar" em questões / recursos).

+1

+1

+1

+1

+1

2+ anos depois e ainda não aconteceu ..? será que nunca? = /

+1

+1

+1

+1

+1000

+1

Eu fiz algumas pesquisas sobre como isso poderia ser implementado. Todos os comandos s3 eventualmente acabam usando TransferManager da biblioteca s3transfer . ( referenciado aqui )

Para suportar a adição de uma pasta com PutObject, podemos enviar uma string vazia no parâmetro Body. Não sei se isso é oficialmente suportado. Eu implementei isso aqui:
https://github.com/svleeuwen/s3transfer/commit/b7d3745a995a75c5262950bb798c8c57e481c2b3

Eu gostaria de algum feedback sobre isso de um mantenedor antes de continuar.

+1

minha solução foi montar meu balde com s3fs e rsync da montagem s3 para um diretório no meu diretório inicial.

+1

1 realmente preciso disso ...

+1

Aberto desde 2014? Mesmo? : unamused:

+1

+1

+1

+1

+1

+1

+1

+1

+1

@thenetimp Esta solução é adequada para baldes pequenos. Estamos usando um balde com mais de 15 TB. S3FS fica terrivelmente lento com baldes maiores.

+1

Bom Dia!

Estamos encerrando esse problema aqui no GitHub, como parte de nossa migração para o UserVoice para solicitações de recursos envolvendo o AWS CLI.

Isso nos permitirá fornecer os recursos mais importantes para você, tornando mais fácil pesquisar e mostrar suporte para os recursos que você mais gosta, sem diluir a conversa com relatórios de bug.

Como uma cartilha rápida do UserVoice (se ainda não for familiar): depois que uma ideia é postada, as pessoas podem votar nas ideias e a equipe de produto responderá diretamente às sugestões mais populares.

Importamos solicitações de recursos existentes do GitHub - procure por esse problema lá!

E não se preocupe, esse problema ainda existirá no GitHub para o bem da posteridade. Como é uma importação somente de texto da postagem original para o UserVoice, ainda teremos em mente os comentários e a discussão que já existem aqui sobre o problema do GitHub.

O GitHub continuará sendo o canal para relatar bugs.

Mais uma vez, esse problema agora pode ser encontrado pesquisando o título em: https://aws.uservoice.com/forums/598381-aws-command-line-interface

- A equipe de SDKs e ferramentas da AWS

Esta entrada pode ser encontrada especificamente no UserVoice em: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not-synchronize-s3- pasta-estrutura

bom trabalho Andre, feche um problema e nos dê um link que não esteja relacionado ao problema. De todas as postagens inúteis

O clichê genérico é decepcionante. Eu acho que a linha entre a solicitação de recurso e um relatório de bug pode ser bem borrada. Para evitar que as pessoas pesquisem, a postagem do UserVoice para esta solicitação de recurso está disponível em https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not -synchronize-s3-folder-structu

Com base no feedback da comunidade, decidimos retornar as solicitações de recursos para problemas do GitHub.

+1

+1

+1

+1

+1

+1

+1. Seria um bom recurso para adicionar.

+1

+1

O mesmo problema
awscli == 1.16.74

+1

-1

O comando aws s3 sync já é recursivo, portanto, não há necessidade de uma opção recursiva. Além disso, o comando sync copia apenas coisas que ainda não existem no destino. Se você apontar para uma pasta, ela sincronizará recursivamente tudo dentro que ainda não existe em seu destino de destino. Isso é diferente do comando aws s3 cp. O comando cp copia tudo o que você disser, independentemente de já existir no destino. O comando cp / mv / rb tem uma opção --recursive para copiar / mover / deletar pastas / arquivos recursivamente. Obrigado

@ 3ggaurav o problema é originalmente de 2014, quando me lembro que sync tinha uma opção --recursive .

Além disso, se você for citar uma resposta de estouro de pilha literalmente, geralmente é uma boa prática referenciar / dar crédito a ela.

A resposta do estouro de pilha está aqui.

Ainda sem progresso nisso?

+1