Aws-cli: aws s3 sync не синхронизирует структуру папок s3 локально

Созданный на 12 сент. 2014  ·  100Комментарии  ·  Источник: aws/aws-cli

Синхронизация aws s3 не полностью синхронизирует структуру папок S3 локально, даже если я использую ее с аргументами --delete или --recursive:

aws --version
aws-cli / 1.4.3 Python / 2.7.6 Linux / 3.13.0-35-общий

$ aws s3 ls s3: //s3.testbucket
$ aws s3 ls s3: //s3.testbucket/
$ mkdir s3.testfolder
$ mkdir s3.testfolder / test1
$ aws s3 sync ./s3.testfolder s3: //s3.testbucket/
$ aws s3 ls s3: //s3.testbucket/
$ touch s3.testfolder / test1 / 1
$ aws s3 sync ./s3.testfolder/ s3: //s3.testbucket/
загрузить: s3.testfolder / test1 / 1 в s3: //s3.testbucket/test1/1
$ aws s3 sync ./s3.testfolder s3: //s3.testbucket/
$ mkdir ./s3.testfolder/test-to-delete
$ aws s3 sync s3: //s3.testbucket/ ./s3.testfolder/ --delete --recursive
$ aws s3 sync s3: //s3.testbucket/ ./s3.testfolder/ --delete
$ ls -lah ./s3.testfolder/
всего 60K
drwxrwxr-x 4 tobi tobi 4.0K szept 12 15:24.
drwx ------ 71 тоби тоби 44К сен 12 15:22 ..
drwxrwxr-x 2 tobi tobi 4.0K szept 12 15:23 test1
drwxrwxr-x 2 tobi tobi 4.0K szept 12 15:24 test-to-delete

$ aws s3 ls s3: //s3.testbucket/
ПРЕДВАРИТЕЛЬНЫЙ тест1 /

feature-request s3 s3sync

Самый полезный комментарий

Основываясь на отзывах сообщества, мы решили возвращать запросы функций в проблемы GitHub.

Все 100 Комментарий

Такое поведение известно. Причина, по которой команда sync ведет себя таким образом, заключается в том, что s3 физически не использует каталоги. Есть только ведра и предметы. У объектов есть префиксы, которые действуют как каталоги, но s3 не назначает конкретный физический объект каталогом.

Следовательно, когда происходит синхронизация, в s3 передаются только файлы, потому что s3 не имеет физических каталогов. Поэтому, когда вы пытаетесь синхронизировать пустые каталоги, ничего не загружается, потому что в них нет файлов. После того, как вы поместите элементы в каталог, будет загружен файл (с префиксом, представляющим каталог).

Спасибо, Кайл, это понятно. Я знаю, как S3 хранит файлы, но иногда нам нужна одна и та же структура каталогов в нескольких местах, даже если есть пустые или удалить, если нам больше не нужно.
Хороший пример, если у вас сложная структура каталогов с большим количеством содержимого локально, чем вы синхронизировали с S3. После этого автоматизированный механизм периодически синхронизирует эту структуру с несколькими запущенными экземплярами. Вы обновляете (удаляете) большую часть контента из S3, а затем автоматизируете повторную синхронизацию с местами, где вы использовали раньше. К сожалению, вы обнаружите, что исходная сложная структура каталогов навсегда остается на целевых объектах синхронизации, что может вызвать путаницу, если вы захотите ее проверить или ваша программа попытается использовать эти пустые папки, потому что вам везде нужно всегда одно и то же. Более того, люди, которые используют его с опцией --delete, возможно, раньше использовали эквивалент «rsync» в Linux, который поддерживает синхронизацию папок, поэтому рассчитывается на ту же операцию.
Я думаю, что было бы несложно реализовать переключатель или параметр для инструмента aws, чтобы каким-то образом определять, является ли объект S3 файлом или папкой (список, размер и т. Д.), И создавать / удалять их локально или в корзине S3 (например, список (bucket.list ("", "/"))?

В этом есть смысл. Рассмотрим возможность добавления для него функции.

Это было бы очень полезно и для нашей ситуации. Если бы он был добавлен как опция (--sync-empty-каталогов), люди могли бы использовать его при необходимости.

+1 Очень нужна эта функция

+1. Хотел бы это использовать.

+1

Меня тоже удивило такое поведение, учитывая, что оно называется «синхронизация».
Я могу обойти это в моем конкретном случае использования, но будущие пользователи могут быть избавлены от боли :)

+1 за возможность синхронизировать структуру каталогов! Если вы удаляете папку, она удаляет только содержимое, но оставляет папку позади ...

+1. У меня такие же потребности.

+1 - удивлен, что еще не реализовано. Конечно, в моем случае это не имеет большого значения, и я могу обойти это (или просто использовать файлы-заполнители при создании структур), но было бы полезно, если бы он поддерживался либо s3 sync, либо s3 cp.

+1

s3cmd sync сохраняет структуру папок, но поэтому у него есть некоторые проблемы при предоставлении доступа во время синхронизации, поэтому после этого нужно запустить еще один s3cmd setacl --recursive ...

+1

+1

+1

Всем спасибо за отзывы. Я думаю, что лучший вариант, который я видел, - это добавить параметр --sync-empty-directories . Давайте сделаем это.

@jamesls Я ожидаю, что функции будут чем-то похожи на rsync, но s3 как хранилище объектов определенно не то же самое.

+1

+1

Есть сроки для этой функции?

В качестве временного обходного пути я добавил пустой файл .s3keep в пустые каталоги, и он у меня работает. Это хитрость, которую я обычно использую, чтобы обмануть git, чтобы он не рассматривал пустые каталоги как пустые :)

Позволит ли это также «удалить / удалить» пустые каталоги на S3?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

_ Имеет смысл при переносе данных на s3._

+1

+1 Разбился этим ... Арг ....

+1

+10
Можно обойти это с помощью фиктивных файлов, но было бы чище, если бы была возможность принудительно синхронизировать пустой префикс.

+1. Пример использования: резервное копирование репозитория svn.

В более общем смысле:
aws s3 синхронизация вещь
aws s3 синхронизацияthing_copy

Я ожидал, что thing_copy точно совпадет с этим.

+1

+1

+1

+1 нужно удалить пустые каталоги

Как продвигается добавление этой опции --sync-empty-directories ?
есть отзывы от команды AWS?
Спасибо.

+1 была бы очень полезной функцией для очень полезного инструмента

+1

+1 (я тоже хочу, чтобы эта функция была реализована, и желаю, чтобы у Github.com был интерфейс, подобный StackOverflow.com, для «голосования» по вопросам / функциям).

+1

+1

+1

+1

+1

2+ года спустя, а этого до сих пор не произошло ..? будет ли это когда-нибудь? знак равно

+1

+1

+1

+1

+1000

+1

Я немного покопался, как это можно реализовать. Все команды s3 в конечном итоге используют TransferManager из библиотеки s3transfer . ( ссылка здесь )

Для поддержки добавления папки с PutObject мы можем отправить пустую строку в параметре Body. Я не знаю, поддерживается ли это официально. Я реализовал это здесь:
https://github.com/svleeuwen/s3transfer/commit/b7d3745a995a75c5262950bb798c8c57e481c2b3

Прежде чем продолжить, я хотел бы получить обратную связь по этому поводу от сопровождающего.

+1

Мое решение состояло в том, чтобы смонтировать мое ведро с s3fs и rsync из монтирования s3 в каталог в моем домашнем каталоге.

+1

+1 очень нужно это ...

+1

Открыто с 2014 года? Действительно? : unamused:

+1

+1

+1

+1

+1

+1

+1

+1

+1

@thenetimp Это решение подходит для небольших ведер. Мы используем ведро объемом более 15 ТБ. S3FS становится ужасно медленной с большими ведрами.

+1

Доброе утро!

Мы закрываем эту проблему здесь, на GitHub, в рамках перехода на UserVoice для запросов функций с использованием интерфейса командной строки AWS.

Это позволит нам предоставить вам наиболее важные функции, упростив поиск и поддержку наиболее важных для вас функций, не разбавляя разговор отчетами об ошибках.

В качестве краткого руководства по UserVoice (если вы еще не знакомы): после публикации идеи люди могут проголосовать за нее, и команда продукта будет отвечать непосредственно на самые популярные предложения.

Мы импортировали существующие запросы функций из GitHub - поищите там эту проблему!

И не волнуйтесь, эта проблема все еще будет существовать на GitHub для будущих поколений. Поскольку это только текстовый импорт исходного сообщения в UserVoice, мы по-прежнему будем помнить о комментариях и обсуждениях, которые уже существуют здесь по проблеме GitHub.

GitHub останется каналом для сообщений об ошибках.

И снова эту проблему теперь можно найти, выполнив поиск по названию на: https://aws.uservoice.com/forums/598381-aws-command-line-interface.

-Команда разработчиков SDK и инструментов AWS

Эту запись, в частности, можно найти на UserVoice по адресу: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not-synchronize-s3- папка-структура

отличная работа, Андре, закройте вопрос и дайте нам ссылку, не имеющую отношения к проблеме. Из всех бесполезных постов

Универсальный шаблон разочаровывает. Я думаю, что грань между запросом функции и отчетом об ошибке может быть довольно размытой. Чтобы избавить людей от необходимости искать этот запрос функции, сообщение UserVoice доступно по адресу https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not -synchronize-s3-folder-structu

Основываясь на отзывах сообщества, мы решили возвращать запросы функций в проблемы GitHub.

+1

+1

+1

+1

+1

+1

+1. Было бы неплохо добавить.

+1

+1

Та же проблема
awscli == 1.16.74

+1

-1

Команда aws s3 sync уже является рекурсивной, поэтому нет необходимости в рекурсивной опции. Кроме того, команда sync копирует только те вещи, которые еще не существуют в месте назначения. Если вы укажете папку, она будет рекурсивно синхронизировать все, что еще не существует в вашем целевом месте назначения. Это отличается от команды aws s3 cp. Команда cp копирует все, что вы ей говорите, независимо от того, что это уже существует на цели. Команда cp / mv / rb принимает параметр --recursive для рекурсивного копирования / перемещения / удаления папок / файлов. Спасибо

@ 3ggaurav, проблема sync была опция --recursive .

Кроме того, если вы собираетесь дословно процитировать ответ о переполнении стека, обычно рекомендуется ссылаться на него / отдавать ему должное.

Ответ на переполнение стека здесь.

По-прежнему нет прогресса в этом вопросе?

+1

Была ли эта страница полезной?
0 / 5 - 0 рейтинги