No they aren’t and they got structure internally. Just wanted to ensure that it’s okay to see only 2 folders and nothing else there.
Now that’s VERY useful information. Maybe not include Option 2 at all since it could break many things. Infact in option 1 I’d probably highlight that one shouldn’t change the bucket for the uploads since it would require a rebake etc, only change the bucket for backups.
This is exactly what was looking for, don’t touch the upload, just move Backups to a new bucket or a sub folder.
Encontrei um problema semelhante, mas com uma causa diferente. Os uploads para o bucket de backup funcionaram, mas o bucket de uploads não.
Acontece que o bucket de uploads estava configurado para bloquear todo o acesso público. (O que, creio eu, é o padrão atualmente.) Quando testei o upload localmente, funcionou normalmente, mas o Discourse estava fazendo o upload com permissão “public-read”, e o S3 rejeitou isso. (Eu teria apostado que o S3 salvaria o status “public-read” no arquivo e, em seguida, rejeitaria as tentativas de acesso público.) Acabei tendo que implementar logs extras para descobrir quais opções estavam sendo usadas no upload.
Talvez o Discourse pudesse usar a API GetPublicAccessBlock para verificar se o bucket está configurado corretamente ao definir a configuração “s3 upload bucket”?
Outra possibilidade é começarmos a recomendar que as pessoas coloquem um CDN CloudFront na frente de seu bucket de uploads no guia de configuração, caso em que o bloqueio de leitura pública deve permanecer em vigor.
Não tenho certeza de como deve ser o equilíbrio entre custo e complexidade nesse cenário.