Aws-cli: AWS S3 Sync синхронизирует не все файлы

Вы можете использовать --exact-timestamps чтобы обойти это, хотя это может привести к избыточным загрузкам, если вы загружаете.

Не могли бы вы дать мне некоторую информацию об одном из файлов, который не синхронизируется, чтобы помочь в воспроизведении?

• Каков точный размер файла локально?
• Каков точный размер файла в S3?
• Какое время последнего изменения локально?
• Какое время последнего изменения в S3?
• Является ли локальный файл символической ссылкой / за символической ссылкой?

Пример выполнения команды
aws s3 синхронизация s3: // ведро / / var / www / folder / --delete

Несколько файлов отсутствуют
Точный местный размер: 2625
Точный s3: 2625
Местное точное время: 06-янв-2017 9:32:31
Отметка точного времени s3: 20-июн-2017 10:14:57
обычный файл в S3 и локальный

Таких случаев несколько в списке из 50 000 файлов. Однако все недостающие в синхронизации разное время 20 июня 2017 года.

Использование --exact-timestamps показывает, что нужно загрузить гораздо больше файлов, хотя их содержимое точно такое же. Однако они по-прежнему отсутствуют в приведенном выше примере.

такая же проблема здесь.
aws s3 sync dist/ s3://bucket --delete не загрузил s3: //bucket/index.html с dist / index.html

dist / index.html и s3: //bucket/index.html имеют одинаковый размер файла, но время их изменения разное.

на самом деле, иногда awscli загружала файл, но иногда нет

То же самое и здесь: --exact-timestamps не помогает - index.html не перезаписывается.

Мы столкнулись с этой проблемой сегодня / на прошлой неделе. И снова index.html имеет тот же размер файла, но его содержимое и время изменения отличаются.

Кто-нибудь знает обходной путь для этого?

Я только что столкнулся с этим. Та же проблема, о которой сообщили @icymind и @samdammers : содержимое моего (локального) файла index.html изменилось, но его размер был таким же, как и у предыдущей копии в S3. Команда {{aws s3 sync}} не загрузила его. Мой «обходной путь» заключался в том, чтобы удалить index.html из S3, а затем снова запустить синхронизацию (которая затем загрузила его, как если бы это был новый файл, я думаю).

Сервер: EC2 linux
Версия: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

После того, как aws s3 sync обработал 270T данных, я потерял несколько ГБ файлов. Синхронизация вообще не копировала файлы со специальными символами.

Пример файла /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

Пришлось использовать cp -R -n

та же проблема здесь xml файл того же размера, но другая временная метка не синхронизируется правильно

Мне удалось воспроизвести эту проблему

bug.tar.gz
скачать прикрепленный tar-файл, а затем

tar -zxvf bug.tar.gz
aws s3 sync a/ s3://<some-bucket-name>/<some_dir>/ --delete
aws s3 sync b/ s3://<some-bucket-name>/<some_dir>/ --delete

вы увидите, что даже если repomd.xml в каталогах a и b различаются по содержимому и временным меткам
попытка синхронизации b ничего не делает

Проверено на
aws-cli / 1.16.88 Python / 2.7.15 Darwin / 16.7.0 ботокор / 1.12.78
aws-cli / 1.16.109 Python / 2.7.5 Linux / 3.10.0-693.17.1.el7.x86_64 botocore / 1.12.99

Я вижу ту же проблему. пытается синхронизировать каталог файлов из s3, где один файл был обновлен, в локальный каталог. этот файл не обновляется в локальном каталоге

Я тоже это вижу. В моем случае это приложение для реагирования с index.html, которое относится к сгенерированным файлам .js. Я синхронизирую их с параметром --delete, чтобы удалить старые файлы, которые больше не упоминаются. Index.html иногда не загружается, в результате получается старый index.html, который указывает на файлы .js, которые больше не существуют.

Следовательно, мой сайт перестает работать !!!

В настоящее время я не понимаю, почему это происходит.

Есть ли у кого-нибудь идеи или обходные пути?

У нас та же проблема, но мы нашли решение. Знаю, не лучший способ, но работает:

aws s3 cp s3://SRC s3://DEST ...
aws s3 sync s3://SRC s3://DEST ... --delete

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

Я добавил --exact-timestamps в свой конвейер, и проблема больше не повторялась. Но, во-первых, это было прерывисто, поэтому я не могу быть уверен, что он это исправил. Если это произойдет снова, я приму предложение

Мы столкнулись с этой проблемой, и --exact-timestamps решает нашу проблему. Не уверен, точно ли это та же проблема.

Я вижу эту проблему, и это очень очевидно, потому что каждый вызов должен копировать только несколько (менее дюжины) файлов.

Ситуация, в которой это происходит, аналогична описанной выше: если папка, в которой находится sync ed, содержит файл с другим содержимым, но с одинаковым размером, sync пропустит копирование нового обновленного файла из S3.

В итоге мы изменили скрипты на aws s3 cp --recursive чтобы исправить это, но это неприятная ошибка - долгое время мы думали, что у нас есть какое-то состояние гонки в нашем собственном приложении, не понимая, что aws-cli просто отказавшись от копирования обновленных файлов.

Я видел это также с файлом html

aws-cli/1.16.168 Python/3.6.0 Windows/2012ServerR2 botocore/1.12.158

Я скопировал вставленную команду s3 sync из сущности GitHub, и на ней было установлено --size-only . Устранение проблемы устранило!

Просто столкнулся с этой проблемой, когда артефакты сборки загружались в корзину. Наш HTML имел тенденцию изменять хэш-коды только для ссылок на ресурсы, поэтому размер всегда был одинаковым. Синхронизация S3 пропускала их, если сборка была слишком ранней после предыдущей. Пример:

10:01 - Запуск сборки 1
10:05 - Сборка 2 заездов
10:06 - Сборка 1 загружена в s3
10:10 - Сборка 2 загружена в s3

Сборка 2 содержит файлы HTML с меткой времени 10:05, однако файлы HTML, загруженные в s3 сборкой 1, имеют метку времени 10:06, поскольку это время создания объектов. Это приводит к тому, что s3 sync игнорирует их, поскольку удаленные файлы «новее», чем локальные.

Теперь я использую s3 cp --recursive за которым следует s3 sync --delete как было предложено ранее.

Надеюсь, это может быть кому-то полезно.

Ранее на этой неделе у меня была такая же проблема; Я не использовал --size-only . Наш index.html отличался одним символом ( . перешел в # ), поэтому размер был таким же, но временная метка на s3 была на 40 минут раньше, чем временная метка нового индекса. .html. Я удалил index.html в качестве временного решения, но невозможно дважды проверять каждое развертывание.

То же самое здесь, файлы с тем же именем, но с разными отметками времени и содержимым не синхронизируются с S3 на локальный и --delete не помогает

У нас такая же проблема. Index.html того же размера, но с более новой меткой времени не копируется.

Об этой проблеме было сообщено более года назад. Почему не исправлено?

Фактически это делает команду snyc бесполезной.

точное время

--exact-timestamps устранили проблему

Меня тоже волнует эта проблема. Я добавил --exact-timestamps, и проблема, похоже, исправила файлы, на которые я смотрел. я не проводил исчерпывающего поиска. У меня порядка 100 тыс. Файлов и 20 ГБ, что намного меньше, чем у других здесь.

Я столкнулся с той же проблемой, aws s3 sync пропускает некоторые файлы, даже с другим содержимым и разными датами. Журнал показывает, что эти пропущенные файлы синхронизируются, но на самом деле нет.
Но когда я снова запускаю aws s3 sync , эти файлы синхронизируются. Очень странно!

У меня была эта проблема при создании сайта с Хьюго, и я наконец понял ее. Я использую подмодули для своей темы Hugo и не опускал их на CI. Это вызывало предупреждения в Hugo, но не сбои.

# On local
                   | EN
-------------------+-----
  Pages            | 16
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  7
  Processed images |  0
  Aliases          |  7
  Sitemaps         |  1
  Cleaned          |  0

# On CI
                   | EN  
-------------------+-----
  Pages            |  7  
  Paginator pages  |  0  
  Non-page files   |  0  
  Static files     |  2  
  Processed images |  0  
  Aliases          |  0  
  Sitemaps         |  1  
  Cleaned          |  0  

Как только я обновил подмодули, все заработало, как ожидалось.

Мы также пострадали от этой проблемы, так что платформа отключилась на ~ 18 часов после того, как новый файл vendor/autoload.php не синхронизировался и устарел с vendor/composer/autoload_real.php поэтому не удалось загрузить все приложение.

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

Почему при синхронизации не используются хеши вместо последних изменений? Не имеет смысла.

Для будущих гуглеров я получал отредактированную ошибку:

PHP message: PHP Fatal error:  Uncaught Error: Class 'ComposerAutoloaderInitXXXXXXXXXXXXX' not found in /xxx/xxx/vendor/autoload.php:7
Stack trace:
#0 /xxx/xxx/bootstrap/app.php(3): require_once()
#1 /xxx/xxx/public/index.php(14): require('/xxx/xxx...')
#2 {main}
  thrown in /xxx/xxx/vendor/autoload.php on line 7" while reading response header from upstream: ...
---

Та же проблема, не все файлы синхронизируются, --exact-timestamps не помогло.

aws --version
aws-cli/1.18.22 Python/2.7.13 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.15.22

Я не могу поверить, что этот билет открыт так долго ... та же проблема, где навязчивая идея Amazon с клиентами?

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

• Когда файл синхронизируется или копируется _в_ s3, метка времени, которую он получает в сегменте, представляет собой дату его копирования, которая _ всегда_ новее, чем дата исходного файла. Так работает s3.
• Файлы синхронизируются только в том случае, если размер изменяется или временная метка на целевом устройстве _ более старом_, чем в источнике.
• Это означает, что если исходные файлы обновляются, но размер файлов остается неизменным, а даты для этих измененных файлов предшествуют дате их последнего копирования, s3 sync не будет синхронизировать их снова.
• Использование --exact-timestamps _only_ работает при копировании с s3 на локальный. Он намеренно не включен для локального доступа к s3, потому что временные метки _ никогда_ равны. Поэтому установка его при синхронизации с локального на s3 не имеет никакого эффекта.
• Я не думаю, что s3 вычисляет хеши для загруженных файлов, поэтому нет способа избежать проверки размера файла и даты последней загрузки.

Суть в том, что он работает по назначению, но есть различные варианты использования, когда это нежелательно. Как упоминалось выше, я работал s3 cp --recursive

@ jam13 спасибо за объяснение, теперь все это имеет смысл задним числом!

Тем не менее, я бы сказал, что в настоящее время это плохо документировано (я ожидал, что в документации появится жирное красное предупреждение о том, что --exact-timestamps работает только _ от s3 до local_, а также для s3 cli, чтобы просто выручить, а не тихо игнорирование параметра), и необязательный режим сравнения на основе хешей необходим для реализации надежно работающего режима синхронизации.

Да, документация невелика, и молчаливое игнорирование параметров очень бесполезно. Отсутствие каких-либо комментариев руководства или даже официальных комментариев от AWS по этому поводу за последние 2 года также говорит о многом.

@ jam13 Я

@kyleknap @KaibaLopez @stealthycoin есть ли обновления по этому

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

* When a file is synced or copied _to_ s3, the timestamp it receives on the bucket is the date it was copied, which is _always_ newer than the date of the source file. This is just how s3 works.

* Files are only synced if the size changes, or the timestamp on the target is _older_ than the source.

* This means that if source files are updated but the size of the files remains unchanged and the dates on those changed files pre-date when they were last copied, s3 sync will not sync them again.

* Using `--exact-timestamps` _only_ works when copying from s3 to local. It is deliberately not enabled for local to s3 because the timestamps are _never_ equal. So setting it when syncing from local to s3 has no effect.

* I don't think s3 calculates hashes for uploaded files, so there's no way of avoiding file size and last uploaded date as checks.

Суть в том, что он работает по назначению, но есть различные варианты использования, когда это нежелательно. Как упоминалось выше, я работал s3 cp --recursive

s3 выполняет хэширование объектов, но не полностью узнаваемым способом, если вы не загрузчик , и сохраняет его как знакомый ETag . Проблема в том, что ETag зависит от количества фрагментов и размера фрагмента, использованного при загрузке файла. Если вы не загрузчик, вы, вероятно, не знаете размер блока (но можете получить количество блоков из ETag). Я не знаю, почему это так.

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

Это просто огромная проблема, с которой люди могут неожиданно столкнуться с рассинхронизацией
данные. Есть 100 различных обходных путей, которые могут спасти всех здесь
время чтения этого билета, а также время, потраченное на обнаружение этого
была проблема в их исходном коде. Почему они не могут сделать одно из этих?

Во вторник, 14 апреля 2020 г., в 13:57 Кейт Келли [email protected]
написал:

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

• Когда файл синхронизируется или копируется _в_ s3, метка времени, которую он получает в сегменте, представляет собой дату его копирования, которая _ всегда_ новее, чем дата исходного файла. Так работает s3.

• Файлы синхронизируются только в том случае, если размер изменяется или временная метка на целевом устройстве _ более старом_, чем в источнике.

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

• Использование --exact-timestamps _only_ работает при копировании с s3 на локальный. Он намеренно не включен для локального доступа к s3, потому что временные метки _ никогда_ равны. Поэтому установка его при синхронизации с локального на s3 не имеет никакого эффекта.

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

Суть в том, что он работает так, как задумано, но есть разные варианты использования.
где это нежелательно. Как уже упоминалось выше
<# m_8540343689970969812_issuecomment-534061850> Я работал над этим
используя s3 cp --recursive

s3 выполняет хэширование объектов, но не полностью узнаваемым способом
https://teppen.io/2018/10/23/aws_s3_verify_etags/ и сохраняет это как
знакомый ETag https://en.wikipedia.org/wiki/HTTP_ETag . Эта проблема
заключается в том, что ETag зависит от количества фрагментов и размера фрагментов, которые
файл был загружен в. Если вы не загрузчик, вы, вероятно, не
знать размер блока (но можно получить количество блоков из ETag). я
не знаю, почему это делается именно так.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...Том

Была такая же проблема. Решил это, изменив политику исходного сегмента на:

 "Action": [
                "s3:*"
            ],

У меня была проблема как с cp --recursive и с sync .
Это все решило. У меня было два действия, которые должны были работать нормально, но этого не произошло. Попробуйте и дайте мне знать, решит ли он вашу проблему.

Подключаюсь, чтобы сказать, что у меня тоже была проблема с sync . Единственная причина, по которой я заметил, заключалась в том, что я заклеивал и проверял MHL на обоих концах. sync не сработает, и мне не хватало около 60 ГБ из 890 ГБ, пытаясь пройти, папка за папкой. Затем я нашел этот поток и попробовал cp --recursive и данные снова начали поступать. Проверим MHL в последний раз, как только получу остальные данные.

Написал скрипт для воспроизведения проблемы, использую:
aws-cli / 1.18.34 Python / 2.7.17 Darwin / 19.4.0 ботокоре / 1.13.50

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

#!/bin/bash
PROFILE=foobar #PUT YOUR PROFILE HERE
BUCKET=baz123  #PUT YOUR BUCKET HERE

mkdir -p test/local
mkdir -p test/s3

cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+3 hours"
}
EOF

#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local


#CHANGE 
cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+2 hours"
}
EOF


#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local

@htrappmann Пожалуйста, прочтите ответ @ jam13 https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 раньше - это не ошибка, это особенность!

Спасибо за подсказку @applerom , но я действительно не могу понять, как @ jam13 объявляет, что это "работает как задумано". Инструмент синхронизации должен быть спроектирован таким образом, чтобы источник и место назначения оставались равными, а в данной синхронизации этого просто нет. Что делает его бесполезным для многих приложений.

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

Спасибо за подсказку @applerom , но я действительно не могу понять, как @ jam13 объявляет, что это "работает как задумано". Инструмент синхронизации должен быть спроектирован таким образом, чтобы источник и место назначения оставались равными, а в данной синхронизации этого просто нет. Что делает его бесполезным для многих приложений.

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

Похоже, он делает неправильные вещи, не так ли.

Я провел еще несколько тестов, чтобы увидеть, что мне действительно нужно сделать, чтобы произошла загрузка:

ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch -m -t 201901010000 test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local

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

При изменении времени модификации на «сейчас» (чтобы локальный файл был новее, чем удаленный), s3 sync _ загружает файл!

Я не мог понять этого, поэтому я проверил документы, в которых говорится (при описании опции --exact-timestamps ):

По умолчанию элементы одинакового размера игнорируются, если локальная версия не новее версии S3.

Использование --exact-timestamps для загрузки работает должным образом (любая разница во временных метках приводит к копированию), но это значение по умолчанию кажется мне обратным.

Возможно, вместо того, чтобы говорить «работает как задумано», я должен был сказать «работает как задокументировано».

@ jam13 Вау, это так странно, и я подумал, что это путаница в документации!
Но если это новый способ исправления ошибок, просто явно поместив их в документацию ...

@ jam13

Я не уверен, что мы можем исключить проблему с часовым поясом.
Каждый день, когда я делаю первое изменение в консоли s3 и синхронизирую aws s3 sync s3://$BUCKET . , она синхронизируется. Если я сделаю еще одно изменение в файле, а затем синхронизирую, он не синхронизируется.
Но работает на следующий день.

Это заставляет меня переосмыслить, может ли это быть из-за часового пояса.

Итак, проверил немного больше о команде touch -m о которой вы упомянули выше.

touch -m -t 201901010000 test/local/test.json
При изменении времени модификации файла на прошлый год синхронизация s3 по-прежнему не загружает файл, поэтому это не просто проблема часового пояса.

Приведенная выше команда touch отображает только время mtime. Он не имеет (и не может) датировать ctime задним числом.
Может ли S3 cli использовать ctime?

$ touch file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Mon Jul 20 21:59:11 2020
Change: Mon Jul 20 21:59:11 2020

$ touch -m -t 201901010000 file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Tue Jan  1 00:00:00 2019
Change: Mon Jul 20 22:01:48 2020

Я думаю, что синхронизация файлов должна гарантировать, что файлы локально и удаленно одинаковы. Я не думаю, что говорю это несправедливо. Я думаю, что aws s3 sync больше похоже на update , чем на синхронизацию. Теперь я собираюсь изменить каждую реализацию aws s3 sync на aws s3 cp --recursive .

Спасибо @ jam13 за объяснение на https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439