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.
Привет,
У меня возникла похожая проблема, но по другой причине. Загрузка в бакет резервных копий работала, а загрузка в бакет для файлов — нет.
Оказалось, что причина в том, что бакет для файлов был настроен на блокировку всех публичных обращений. (Кажется, сейчас это настройка по умолчанию.) При локальном тестировании загрузка работала нормально, но Discourse пытался загружать файлы с доступом «public-read», и S3 отклонял такие запросы. (Я думал, что S3 просто сохранит статус «public-read» для файла, а затем будет блокировать попытки публичного доступа.) В итоге мне пришлось добавить дополнительное логирование, чтобы понять, какие именно параметры используются при загрузке.
Возможно, Discourse мог бы использовать API GetPublicAccessBlock, чтобы проверять правильность конфигурации бакета при настройке параметра «s3 upload bucket»?
Другой вариант — начать рекомендовать пользователям размещать CDN CloudFront перед их бакетом для загрузки в руководстве по настройке. В этом случае ограничение public-read должно оставаться в силе.
Я не уверен, каким должен быть баланс между затратами и сложностью в данном случае.