Aws-cli: AWSS3同期はすべてのファイルを同期するわけではありません

--exact-timestampsを使用してこれを回避できる可能性がありますが、アップロードしている場合は過剰なアップロードが発生する可能性があります。

再現に役立てるために、同期していないファイルの1つに関する情報を教えてください。

• ローカルでの正確なファイルサイズはどれくらいですか？
• S3の正確なファイルサイズはどれくらいですか？
• ローカルで最後に変更された時刻は何ですか？
• S3で最後に変更された時刻は何ですか？
• ローカルファイルはシンボリックリンク/シンボリックリンクの背後にありますか？

コマンド実行の例
aws s3 sync s3：// bucket / / var / www / folder / --delete

いくつかのファイルがありません
正確なローカルサイズ：2625
正確なs3：2625
ローカルの正確なタイムスタンプ：2017年1月6日9:32:31
正確なタイムスタンプs3：2017年6月20日10:14:57
S3およびローカルの通常のファイル

約50,000個のファイルのリストにそのようなケースがいくつかあります。 ただし、同期されていないものはすべて、2017年6月20日のさまざまな時点です。

--exact-timestampsを使用すると、まったく同じ内容ですが、ダウンロードするファイルがはるかに多くなります。 ただし、上記の例ではまだ欠落しています。

ここで同じ問題。
aws s3 sync dist/ s3://bucket --deleteはdist / index.htmlでs3：//bucket/index.htmlをアップロードしません

dist / index.htmlとs3：//bucket/index.htmlのファイルサイズは同じですが、変更時間は異なります。

実際、awscliがファイルをアップロードした場合もあれば、アップロードしなかった場合もあります。

ここでも同じですが、 --exact-timestampsは役に立ちません- index.htmlは上書きされません。

この問題は今日/先週は順調でした。 ここでも、index.htmlは同じファイルサイズですが、内容と変更時刻が異なります。

誰かがこれの回避策を知っていますか？

私はちょうどこれに遭遇しました。 @icymindと@samdammersによって報告されたのと同じ問題：私の（ローカル） index.htmlファイルの内容が変更されましたが、そのファイルサイズはS3の以前のコピーと同じでした。 {{aws s3sync}}コマンドはアップロードしませんでした。 私の「回避策」は、S3からindex.htmlを削除してから、同期を再度実行することでした（これにより、新しいファイルであるかのようにアップロードされたと思います）。

サーバー： 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を超えるデータを実行した後、数GBのファイルを失いました。 Syncは、特殊文字を含むファイルをまったくコピーしませんでした。

ファイルの例/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

ディレクトリaとbのrepomd.xmlの内容とタイムスタンプが異なっていても、
bを同期しようとしても何も起こりません

テスト済み
aws-cli / 1.16.88 Python / 2.7.15 Darwin / 16.7.0 botocore / 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

同じ問題が発生しています。 1つのファイルがローカルディレクトリに更新されたs3からファイルのディレクトリを同期しようとしています。 そのファイルはローカルディレクトリで更新されません

私もこれを見ています。 私の場合、生成された.jsファイルを参照するindex.htmlを使用したreactアプリです。 --deleteオプションと同期して、参照されなくなった古いファイルを削除します。 index.htmlがアップロードされないことがあり、その結果、存在しなくなった.jsファイルを指す古いindex.htmlが生成されます。

したがって、私のウェブサイトは機能しなくなります!!!

私は現在、なぜこれが起こっているのかについて無知です。

誰かが何かアイデアや回避策を持っていますか？

同じ問題がありますが、回避策が見つかりました。 私は知っています、それは最善の方法ではありませんが、それは機能します：

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

コピーは正常に機能しているように思われるので、最初にコピーしてから、syncコマンドを使用して、存在しなくなったファイルを削除します。
問題ができるだけ早く修正されることを願っています。

パイプラインに--exact-timestampsを追加しましたが、問題は再発していません。 しかし、そもそも断続的だったので、直ったかどうかはわかりません。 それが再び起こるならば、私は@ marns93の提案で行きます。

この問題は発生し、 --exact-timestamps問題が解決しました。 それがまったく同じ問題であるかどうかはわかりません。

この問題が発生していますが、各呼び出しでコピーする必要があるのはほんの一握り（1ダース未満）のファイルであるため、非常に明白です。

それが発生する状況は、上記で報告されたものと同じですsync編集されているフォルダーに、ファイルの内容が異なるがファイルサイズが同じファイルが含まれている場合、 syncは新しい更新されたファイルのコピーをスキップします。 S3。

スクリプトをaws s3 cp --recursiveして修正しましたが、これは厄介なバグです。長い間、aws-cliが単純であることに気づかずに、独自のアプリケーションに何らかの競合状態があると考えていました。更新されたファイルをコピーしないことを選択します。

これもhtmlファイルで見ました

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

GitHubの要点からs3 syncコマンドをコピーして貼り付けたところ、 --size-only設定されていました。 それを削除すると問題が解決しました！

ビルドアーティファクトがバケットにアップロードされているときに、この問題が発生しました。 HTMLはアセットリンクのハッシュコードのみを変更する傾向があるため、サイズは常に同じでした。 ビルドが前のビルドよりも早すぎる場合、S3同期はこれらをスキップしていました。 例：

10：01-ビルド1の実行
10：05-ビルド2の実行
10：06-ビルド1がs3にアップロードされます
10：10-ビルド2がs3にアップロードされます

ビルド2にはタイムスタンプが10:05のHTMLファイルがありますが、ビルド1によってs3にアップロードされたHTMLファイルのタイムスタンプは10:06です。これは、オブジェクトが作成されたときのことです。 これにより、リモートファイルはローカルファイルよりも「新しい」ため、s3同期では無視されます。

以前に提案したように、現在s3 cp --recursiveにs3 sync --deleteを使用しています。

これが誰かに役立つことを願っています。

今週初めに同じ問題が発生しました。 --size-onlyを使用していません.は# ）、サイズは同じでしたが、s3のタイムスタンプは新しいインデックスのタイムスタンプより40分早かったです。 .html。 一時的な回避策としてindex.htmlを削除しましたが、すべてのデプロイメントを再確認することは不可能です。

ここでも同じですが、同じ名前でタイムスタンプとコンテンツが異なるファイルはS3からローカルに同期されず、-deleteは役に立ちません

同じ問題が発生します。 同じサイズでタイムスタンプが新しいindex.htmlはコピーされません。

この問題は1年以上前に報告されました。 なぜ修正されないのですか？

実際には、snycコマンドは役に立たなくなります。

正確な時間

--exact-timestampsで問題が修正されました

私もこの問題の影響を受けています。 --exact-timestampsを追加しましたが、この問題により、探していたファイルが修正されたようです。 私は徹底的な検索をしていません。 私は100kファイルと20GBのオーダーで、ここにある他のファイルよりもはるかに少ないです。

同じ問題に直面しました。内容や日付が異なっていても、 aws s3 sync一部のファイルをスキップします。 ログには、スキップされたファイルが同期されているが、実際には同期されていないことが示されています。
しかし、 aws s3 sync再度実行すると、これらのファイルが同期されました。 とても変だ！

Hugoでサイトを構築するときにこの問題が発生し、ついにそれを理解しました。 私は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  

サブモジュールを更新すると、すべてが期待どおりに機能しました。

また、この問題の影響も受けているため、新しいvendor/autoload.phpファイルが同期されなかった後、プラットフォームが約18時間ダウンし、 vendor/composer/autoload_real.phpで古くなっていました。アプリ全体を読み込めませんでした。

これは_非常に_奇妙な問題であり、この問題がこれほど長い間開かれているとは信じられません。

同期が最終変更の代わりにハッシュを使用しないのはなぜですか？ 0の意味があります。

将来のGoogle社員のために、私が得ていた編集済みのエラー：

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の仕組みです。
• サイズが変更された場合、またはターゲットのタイムスタンプがソースよりも_古い_場合にのみ、ファイルが同期されます。
• つまり、ソースファイルが更新されてもファイルのサイズが変更されず、変更されたファイルの日付が最後にコピーされた日付よりも前の場合、s3syncはそれらを再度同期しません。
• --exact-timestamps _only_の使用
• s3がアップロードされたファイルのハッシュを計算するとは思わないので、ファイルサイズと最後にアップロードされた日付をチェックとして回避する方法はありません。

結論としては、意図したとおりに機能するということですが、これが望ましくないさまざまなユースケースがあります。 上で述べたs3 cp --recursiveを使用してそれを回避しました

@ jam13説明に感謝します、今ではすべてが後知恵で理にかなっています！

それにもかかわらず、私はそれが現在十分に文書化されていないことを主張します（ --exact-timestampsは_s3からlocal_までのみ機能し、s3 cliはサイレントではなく単にベイルアウトすることを示す、ドキュメントの真っ赤な警告を期待していましたパラメータを無視して）、オプションのハッシュベースの比較モードは、確実に機能する同期モードを実装するために必要です。

はい、ドキュメントは素晴らしいものではなく、オプションを黙って無視することは非常に役に立ちません。 過去2年間にAWSからのこのチケットに関する管理者の不在、または公式のコメントさえも、ボリュームを物語っています。

@ 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の異なる回避策があります
このチケットを読んだ時間と、これを発見するのに費やした時間
彼らのソースコードの問題でした。 なぜ彼らはこれらの1つを行うことができないのですか？

2020年4月14日火曜日午後1時57分キースケリー[email protected]
書きました：

このチケットが少し前に閉じられていなかったなんて信じられません。 私ができる限り
教えてください、それは設計どおりに機能しますが、ユーザー（私を含む）は
それがどのように機能するべきか、そしてそれが彼らのように振る舞わないときに驚かされる
期待される。

• ファイルがs3に同期またはコピーされると、バケットで受信するタイムスタンプはコピーされた日付であり、ソースファイルの日付よりも常に新しい日付です。 これがs3の仕組みです。

• サイズが変更された場合、またはターゲットのタイムスタンプがソースよりも_古い_場合にのみ、ファイルが同期されます。

• つまり、ソースファイルが更新されてもファイルのサイズが変更されず、変更されたファイルの日付が最後にコピーされた日付よりも前の場合、s3syncはそれらを再度同期しません。

• --exact-timestamps _only_の使用

• s3がアップロードされたファイルのハッシュを計算するとは思わないので、ファイルサイズと最後にアップロードされた日付をチェックとして回避する方法はありません。

結論としては、意図したとおりに機能しますが、さまざまなユースケースがあります
これが望ましくない場合。 上記のように
<＃m_8540343689970969812_issuecomment-534061850>回避しました
s3cpを使用する--recursive

s3はオブジェクトをハッシュしますが、完全に理解できる方法ではありません
https://teppen.io/2018/10/23/aws_s3_verify_etags/ 、これを次のように保存します
おなじみのETaghttps ：//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両方に問題がありました。
これですべて解決しました。 うまくいくはずの2つのアクションがありましたが、うまくいきませんでした。 それを試してみて、それがあなたの問題を解決したかどうか私に知らせてください。

ここでチャイムを鳴らして、私もsync問題を抱えていると言います。 私が気付いた唯一の理由は、両端のMHLを封印して検証していたためです。 syncは機能せず、890GBのうち約60GBが不足していて、フォルダーごとに調べようとしました。 次に、このスレッドを見つけてcp --recursiveを試したところ、データが再び流れ始めました。 このデータの残りを取得したら、最後にもう一度MHLを検証します。

問題を再現するためのスクリプトを作成しました。次を使用します。
aws-cli / 1.18.34 Python / 2.7.17 Darwin / 19.4.0 botocore / 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 syncはファイルをダウンロードしないため、単にタイムゾーンの問題ではありません。

変更時刻を現在に変更すると（ローカルファイルがリモートよりも新しいため）、s3syncはファイルをダウンロードします。

私はそれを理解できなかったので、ドキュメントをチェックしました。その状態は（ --exact-timestampsオプションを説明するとき）：

デフォルトの動作では、ローカルバージョンがS3バージョンよりも

ダウンロードに--exact-timestampsを使用すると、期待どおりに機能します（タイムスタンプに違いがあるとコピーになります）が、このデフォルトは私には逆に思えます。

「設計どおりに機能する」と言う代わりに、「文書化されたとおりに機能する」と言うべきだったのかもしれません。

@ jam13うわー、それはとても奇妙です、そして私はそれがドキュメンテーションの混乱だと思いました！
しかし、これがバグを修正する新しい方法である場合は、ドキュメントに明示的に配置するだけです...

@ jam13

タイムゾーンの問題を除外できるかどうかはわかりません。
毎日、s3コンソールで最初の変更を行い、 aws s3 sync s3://$BUCKET .を同期すると、同期されます。 ファイルに別の変更を加えてから同期すると、同期されません。
しかし、それは翌日機能します。

これは、タイムゾーンが原因である可能性があるかどうかを再考させます。

それで、あなたが上で述べたtouch -mコマンドについてもう少しチェックしました。

touch -m -t 201901010000 test/local/test.json
ファイルの変更時刻を昨年に変更しても、s3 syncはファイルをダウンロードしないため、単にタイムゾーンの問題ではありません。

上記の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ます。

https://github.com/aws/aws-cli/issues/3273#issuecomment-602514439で説明してくれたます