Aws-cli: AWS S3-Sync synchronisiert nicht alle Dateien

Sie können möglicherweise --exact-timestamps , um dies zu umgehen, obwohl dies beim Hochladen zu übermäßigen Uploads führen kann.

Könnten Sie mir bei der Reproduktion helfen, Informationen zu einer der Dateien zu erhalten, die nicht synchronisiert wird?

• Was ist die genaue Dateigröße lokal?
• Was ist die genaue Dateigröße in S3?
• Was ist die letzte lokale Änderungszeit?
• Was ist die letzte Änderungszeit in S3?
• Ist die lokale Datei ein Symlink / hinter einem Symlink?

Beispielbefehlsausführung
aws s3 sync s3://bucket/ /var/www/folder/ --delete

Mehrere Dateien fehlen
Genaue lokale Größe: 2625
Genau s3: 2625
Genauer Zeitstempel lokal: 06.01.2017 9:32:31
Genauer Zeitstempel s3: 20.06.2017 10:14:57
normale Datei in S3 und lokal

In einer Liste von rund 50.000 Dateien gibt es mehrere solcher Fälle. Alle fehlenden Synchronzeiten sind jedoch am 20. Juni 2017 zu verschiedenen Zeiten.

Die Verwendung von --exact-timestamps zeigt viel mehr Dateien zum Herunterladen an, obwohl sie genau den gleichen Inhalt haben. Allerdings fehlen ihnen noch die im obigen Beispiel.

gleiches Problem hier.
aws s3 sync dist/ s3://bucket --delete hat s3://bucket/index.html nicht mit dist/index.html hochgeladen

dist/index.html und s3://bucket/index.html haben dieselbe Dateigröße, aber ihre Änderungszeit ist unterschiedlich.

tatsächlich hat awscli die Datei manchmal hochgeladen, aber manchmal nicht

Auch hier hilft --exact-timestamps nicht - index.html wird nicht überschrieben.

Wir erlebten, dass dieses Problem heute/letzte Woche gut war. Auch hier hat index.html dieselbe Dateigröße, aber der Inhalt und die Änderungszeiten sind unterschiedlich.

Kennt jemand einen Workaround dafür?

Ich bin gerade darauf gestoßen. Dasselbe Problem wie von @samdammers gemeldet : Der Inhalt meiner (lokalen) index.html Datei hatte sich geändert, aber die Dateigröße war dieselbe wie bei der früheren Kopie in S3. Der Befehl {{aws s3 sync}} hat es nicht hochgeladen. Meine "Problemumgehung" bestand darin, index.html aus S3 zu löschen und dann die Synchronisierung erneut auszuführen (wobei sie dann hochgeladen wurde, als wäre es eine neue Datei, denke ich).

Server: EC2 linux
Version: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

Nachdem aws s3 sync über 270T an Daten ausgeführt hatte, verlor ich einige GB an Dateien. Sync hat keine Dateien mit Sonderzeichen kopiert.

Beispiel für Datei /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

Musste cp -R -n

gleiches Problem hier XML-Datei der gleichen Größe, aber unterschiedlicher Zeitstempel nicht korrekt synchronisiert

Ich konnte dieses Problem reproduzieren

bug.tar.gz
Laden Sie die angehängte Tar-Datei herunter und dann

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

Sie werden das sehen, obwohl sich repomd.xml in den Verzeichnissen a und b in Inhalt und Zeitstempeln unterscheidet
Der Versuch, b zu synchronisieren, führt zu nichts

Getestet auf
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

ich sehe das gleiche Problem. versucht, ein Verzeichnis mit Dateien von s3 zu synchronisieren, in dem eine Datei mit einem lokalen Verzeichnis aktualisiert wurde. diese Datei wird im lokalen Verzeichnis nicht aktualisiert

Das sehe ich auch. In meinem Fall ist es eine React-App mit index.html, die auf generierte .js-Dateien verweist. Ich synchronisiere sie mit der Option --delete, um alte Dateien zu löschen, auf die nicht mehr Bezug genommen wird. Die index.html wird manchmal nicht hochgeladen, was zu einer alten index.html führt, die auf .js-Dateien verweist, die nicht mehr existieren.

Daher funktioniert meine Website nicht mehr !!!

Ich bin derzeit ahnungslos, warum das passiert.

Hat jemand Ideen oder Workarounds?

Wir haben das gleiche Problem, haben aber gerade einen Workaround gefunden. Ich weiß, es ist nicht der beste Weg, aber es funktioniert:

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

Es scheint uns, dass das Kopieren gut funktioniert, also kopieren wir zuerst, dann verwenden wir den sync-Befehl, um Dateien zu löschen, die nicht mehr vorhanden sind.
Hoffe, dass das Problem so schnell wie möglich behoben wird.

Ich habe --exact-timestamps zu meiner Pipeline hinzugefügt und das Problem ist nicht wieder aufgetreten. Aber es war in erster Linie zeitweilig, daher kann ich nicht sicher sein, ob es behoben wurde. Wenn es wieder passiert, werde ich dem Vorschlag von @marns93 folgen .

Wir sind auf dieses Problem gestoßen und --exact-timestamps behebt unser Problem. Ich bin mir nicht sicher, ob es genau das gleiche Problem ist.

Ich sehe dieses Problem, und es ist sehr offensichtlich, da jeder Anruf nur eine Handvoll (unter einem Dutzend) Dateien kopieren muss.

Die Situation, in der dies geschieht, ist genau wie oben beschrieben: Wenn der Ordner, in den sync eingefügt wird, eine Datei mit anderem Dateiinhalt, aber identischer Dateigröße enthält, überspringt sync das Kopieren der neuen aktualisierten Datei von S3.

Am Ende haben wir die Skripte in aws s3 cp --recursive geändert, um das Problem zu beheben, aber das ist ein übler Fehler -- lange dachten wir, wir hätten eine Art Race Condition in unserer eigenen Anwendung, ohne zu wissen, dass aws-cli einfach war die Entscheidung, die aktualisierte(n) Datei(en) nicht zu kopieren.

Ich habe das auch mit einer HTML-Datei gesehen

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

Ich habe den Befehl s3 sync aus einem GitHub-Gist kopiert und darin --size-only festgelegt. Das Entfernen hat das Problem behoben!

Ich bin gerade auf dieses Problem gestoßen, bei dem Build-Artefakte in einen Bucket hochgeladen wurden. Unser HTML änderte in der Regel nur Hash-Codes für Asset-Links, sodass die Größe immer gleich war. Die S3-Synchronisierung übersprang diese, wenn der Build zu früh nach einem vorherigen erfolgte. Beispiel:

10:01 - Baue 1 Läufe
10:05 - Baue 2 Läufe
10:06 - Build 1 wird auf s3 hochgeladen
10:10 - Build 2 wird auf s3 hochgeladen

Build 2 hat HTML-Dateien mit einem Zeitstempel von 10:05, die von Build 1 in s3 hochgeladenen HTML-Dateien haben jedoch einen Zeitstempel von 10:06, da die Objekte zu diesem Zeitpunkt erstellt wurden. Dies führt dazu, dass sie von s3 sync ignoriert werden, da Remote-Dateien "neuer" sind als lokale Dateien.

Ich verwende jetzt s3 cp --recursive gefolgt von s3 sync --delete wie zuvor vorgeschlagen.

Hoffe, das kann jemandem hilfreich sein.

Ich hatte das gleiche Problem Anfang dieser Woche; Ich habe --size-only . Unsere index.html unterschied sich um ein einzelnes Zeichen ( . zu # ), also war die Größe gleich, aber der Zeitstempel auf s3 war 40 Minuten früher als der Zeitstempel des neuen Index .html. Ich habe die index.html als vorübergehende Problemumgehung gelöscht, aber es ist nicht möglich, jede Bereitstellung noch einmal zu überprüfen.

Das gleiche hier, Dateien mit demselben Namen, aber mit unterschiedlichem Zeitstempel und Inhalt werden nicht von S3 nach lokal synchronisiert und --delete hilft nicht

Wir erleben das gleiche Problem. Eine index.html mit gleicher Größe, aber neuerem Zeitstempel wird nicht kopiert.

Dieses Problem wurde vor über einem Jahr gemeldet. Warum ist es nicht behoben?

Tatsächlich macht es den snyc-Befehl nutzlos.

genaue Zeit

--exact-timestamps hat das Problem behoben

Auch ich bin von diesem Thema betroffen. Ich fügte --exact-timestamps hinzu und das Problem schien die Dateien zu beheben, die ich mir angesehen hatte. ich habe keine erschöpfende Suche durchgeführt. Ich habe in der Größenordnung von 100.000 Dateien und 20 GB, viel weniger als die anderen hier.

Ich habe das gleiche Problem gehabt, aws s3 sync überspringe einige Dateien, sogar mit unterschiedlichem Inhalt und unterschiedlichem Datum. Das Protokoll zeigt, dass diese übersprungenen Dateien synchronisiert werden, aber tatsächlich nicht.
Aber wenn ich aws s3 sync wieder ausführe, wurden diese Dateien synchronisiert. Sehr merkwürdig!

Ich hatte dieses Problem beim Erstellen einer Website mit Hugo und habe es endlich herausgefunden. Ich verwende Submodule für mein Hugo-Theme und habe sie nicht auf CI gezogen. Dies führte zu Warnungen bei Hugo, aber nicht zu Ausfällen.

# 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  

Nachdem ich die Submodule aktualisiert hatte, funktionierte alles wie erwartet.

Wir waren auch von diesem Problem so sehr betroffen, dass eine Plattform für ~18 Stunden ausfiel, nachdem eine neue vendor/autoload.php Datei nicht synchronisiert wurde und mit vendor/composer/autoload_real.php veraltet war die ganze app konnte nicht geladen werden.

Dies ist ein _sehr_ seltsames Problem, und ich kann nicht glauben, dass das Thema schon so lange offen ist.

Warum sollte eine Synchronisierung keine Hashes anstelle von zuletzt geändert verwenden? Macht 0 Sinn.

Für zukünftige Google-Mitarbeiter ein korrigierter Fehler, den ich erhalten habe:

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: ...
---

Das gleiche Problem, nicht alle Dateien werden synchronisiert, --exact-timestamps hat nicht geholfen.

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

Ich kann nicht glauben, dass dieses Ticket so lange geöffnet ist ... gleiches Problem hier, wo ist die Kundenbesessenheit von Amazon?

Ich kann nicht glauben, dass dieses Ticket nicht vor einiger Zeit geschlossen wurde. Soweit ich das beurteilen kann, funktioniert es wie geplant, aber Benutzer (einschließlich mir) machen Annahmen darüber, wie es funktionieren soll, und sind dann überrascht, wenn es sich nicht so verhält, wie sie es erwartet haben.

• Wenn eine Datei _nach_ s3 synchronisiert oder kopiert wird, ist der Zeitstempel, den sie im Bucket empfängt, das Datum, an dem sie kopiert wurde, das _immer_ neuer ist als das Datum der Quelldatei. So funktioniert s3.
• Dateien werden nur synchronisiert, wenn sich die Größe ändert oder der Zeitstempel auf dem Ziel _älter_ als die Quelle ist.
• Dies bedeutet, dass s3 sync nicht erneut synchronisiert, wenn Quelldateien aktualisiert werden, die Größe der Dateien jedoch unverändert bleibt und die Daten dieser geänderten Dateien vor dem Datum der letzten Kopie liegen.
• Die Verwendung von --exact-timestamps funktioniert _nur_ beim Kopieren von s3 nach lokal. Es ist absichtlich nicht für local to s3 aktiviert, da die Zeitstempel _niemals_ gleich sind. Die Einstellung beim Synchronisieren von lokal zu s3 hat also keine Auswirkung.
• Ich glaube nicht, dass s3 Hashes für hochgeladene Dateien berechnet, daher gibt es keine Möglichkeit, die Dateigröße und das Datum des letzten Hochladens als Überprüfung zu vermeiden.

Unterm Strich funktioniert es wie beabsichtigt, aber es gibt verschiedene Anwendungsfälle, in denen dies nicht wünschenswert ist. Wie oben erwähnt, habe ich es mit s3 cp --recursive

@jam13 danke für die Erklärung, jetzt macht im Nachhinein alles Sinn!

Trotzdem würde ich argumentieren, dass es derzeit schlecht dokumentiert ist (ich hätte eine fette rote Warnung in der Dokumentation erwartet, die besagt, dass --exact-timestamps nur _von s3 zu lokal_ funktioniert und auch, dass die s3-Cli einfach aussteigt anstatt lautlos Ignorieren des Parameters) und ein optionaler Hash-basierter Vergleichsmodus ist notwendig, um einen zuverlässig arbeitenden Synchronisationsmodus zu implementieren.

Ja, die Dokumentation ist nicht großartig, und Optionen stillschweigend zu ignorieren ist sehr wenig hilfreich. Auch das Fehlen jeglicher Management- oder gar offizieller Kommentare zu diesem Ticket von AWS in den letzten 2 Jahren spricht Bände.

@jam13 Ich habe einige Dokumentationen

@kyleknap @KaibaLopez @stealthycoin Gibt es ein Update zu diesem Thema?

Ich kann nicht glauben, dass dieses Ticket nicht vor einiger Zeit geschlossen wurde. Soweit ich das beurteilen kann, funktioniert es wie geplant, aber Benutzer (einschließlich mir) machen Annahmen darüber, wie es funktionieren soll, und sind dann überrascht, wenn es sich nicht so verhält, wie sie es erwartet haben.

* 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.

Unterm Strich funktioniert es wie beabsichtigt, aber es gibt verschiedene Anwendungsfälle, in denen dies nicht wünschenswert ist. Wie oben erwähnt, habe ich es mit s3 cp --recursive

s3 hasht die Objekte, aber nicht auf ganz erkennbare Weise, wenn Sie nicht der Uploader sind , und speichert dies als das bekannte ETag . Das Problem ist, dass das ETag von der Anzahl der Chunks und der Chunk-Größe abhängt, die beim Hochladen der Datei verwendet wurde. Wenn Sie nicht der Uploader sind, kennen Sie wahrscheinlich die Chunk-Größe nicht (können aber die Anzahl der Chunks aus dem ETag abrufen). Ich weiß nicht, warum das so gemacht wird.

Dies funktioniert wahrscheinlich wie beabsichtigt, aber nicht so, wie es sollte. Es sollte trivial sein zu überprüfen, ob sich eine Datei geändert hat

Es ist nur ein großer Fallstrick für die Leute, die unerwartet nicht synchron sind
Daten. Es gibt 100 verschiedene Workarounds, die hier alle retten könnten
die Zeit, in der Sie dieses Ticket gelesen haben, zusammen mit der Zeit, die Sie damit verbracht haben, dies zu entdecken
war ein Problem in ihrem Quellcode. Warum können sie so etwas nicht tun?

Am Di, 14. April 2020 um 13:57 Keith Kelly [email protected]
schrieb:

Ich kann nicht glauben, dass dieses Ticket nicht vor einiger Zeit geschlossen wurde. Soweit ich kann
sagen, es funktioniert wie geplant, aber Benutzer (einschließlich mir) machen Annahmen über
wie es funktionieren soll und sind dann überrascht wenn es sich nicht so verhält wie sie
erwartet.

• Wenn eine Datei _nach_ s3 synchronisiert oder kopiert wird, ist der Zeitstempel, den sie im Bucket empfängt, das Datum, an dem sie kopiert wurde, das _immer_ neuer ist als das Datum der Quelldatei. So funktioniert s3.

• Dateien werden nur synchronisiert, wenn sich die Größe ändert oder der Zeitstempel auf dem Ziel _älter_ als die Quelle ist.

• Dies bedeutet, dass s3 sync nicht erneut synchronisiert, wenn Quelldateien aktualisiert werden, die Größe der Dateien jedoch unverändert bleibt und die Daten dieser geänderten Dateien vor dem Datum der letzten Kopie liegen.

• Die Verwendung von --exact-timestamps funktioniert _nur_ beim Kopieren von s3 nach lokal. Es ist absichtlich nicht für local to s3 aktiviert, da die Zeitstempel _niemals_ gleich sind. Die Einstellung beim Synchronisieren von lokal zu s3 hat also keine Auswirkung.

• Ich glaube nicht, dass s3 Hashes für hochgeladene Dateien berechnet, daher gibt es keine Möglichkeit, die Dateigröße und das Datum des letzten Hochladens als Überprüfung zu vermeiden.

Unterm Strich funktioniert es wie beabsichtigt, aber es gibt verschiedene Anwendungsfälle
wo dies nicht erwünscht ist. Wie oben erwähnt
<#m_8540343689970969812_issuecomment-534061850> Ich habe es umgangen
mit s3 cp --recursive

s3 hasht die Objekte, aber nicht auf eine ganz erkennbare Weise
https://teppen.io/2018/10/23/aws_s3_verify_etags/ und speichert dies als
das bekannte ETag https://en.wikipedia.org/wiki/HTTP_ETag . Das Problem
ist, dass der ETag von der Anzahl der Chunks und der Chunk-Größe abhängt
die Datei wurde hochgeladen. Wenn Sie nicht der Uploader sind, wahrscheinlich nicht
kennen die Chunk-Größe (können aber die Anzahl der Chunks aus dem ETag abrufen). ich
weiß nicht warum das so gemacht wird.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 , oder
Abmelden
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...tom

Hatte das gleiche Problem. Gelöst, indem die Quell-Bucket-Richtlinie geändert wurde in:

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

Ich hatte das Problem mit cp --recursive und sync .
Dies hat alles gelöst. Ich hatte zwei Aktionen, die gut hätten funktionieren sollen, aber nicht funktionierten. Probiere es aus und lass es mich wissen, ob es dein Problem gelöst hat.

Ich melde mich hier, um zu sagen, dass ich auch das Problem mit sync . Der einzige Grund, den ich bemerkte, war, dass ich MHLs an beiden Enden versiegelte und verifizierte. sync würde nicht funktionieren, und mir fehlten etwa 60 GB von 890 GB, als ich versuchte, Ordner für Ordner durchzugehen. Dann fand ich diesen Thread und versuchte cp --recursive und die Daten begannen wieder zu fließen. Werde die MHL ein letztes Mal überprüfen, sobald ich die restlichen Daten habe.

Ich habe ein Skript geschrieben, um das Problem zu reproduzieren, ich benutze:
aws-cli/1.18.34 Python/2.7.17 Darwin/19.4.0 botocore/1.13.50

Wenn Sie das Skript ausführen, sehen Sie, dass nach dem Hochladen der Änderung dieselbe Änderung nicht mehr heruntergeladen wird. Dies ist das Skript:

#!/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 Bitte lesen Sie die @jam13- Antwort https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 vorher - es ist kein Fehler, es ist ein Feature!

Danke für den Hinweis @applerom , aber ich kann wirklich nicht verstehen, wie @jam13 es als "funktioniert wie geplant" deklariert. Ein Synchronisierungstool sollte so konzipiert sein, dass Quelle und Ziel gleich bleiben, und dies ist bei dieser Synchronisierung einfach nicht gegeben. Was es für viele Anwendungen unbrauchbar macht.

Auch wenn die Dateigröße unverändert ist, aber der Quellzeitstempel neuer ist, findet auch keine Synchronisierung statt, wie in meinem Beispielskript.

Danke für den Hinweis @applerom , aber ich kann wirklich nicht verstehen, wie @jam13 es als "funktioniert wie geplant" deklariert. Ein Synchronisierungstool sollte so konzipiert sein, dass Quelle und Ziel gleich bleiben, und dies ist bei dieser Synchronisierung einfach nicht gegeben. Was es für viele Anwendungen unbrauchbar macht.

Auch wenn die Dateigröße unverändert ist, aber der Quellzeitstempel neuer ist, findet auch keine Synchronisierung statt, wie in meinem Beispielskript.

Das sieht so aus, als würde es das Falsche tun, nicht wahr.

Ich habe ein paar andere Tests durchgeführt, um zu sehen, was ich tatsächlich tun musste, um den Download durchzuführen:

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

Wenn die Änderungszeit der Datei auf letztes Jahr geändert wird, lädt die s3-Synchronisierung die Datei immer noch nicht herunter, sodass es sich nicht nur um ein Zeitzonenproblem handelt.

Wenn die Änderungszeit auf jetzt geändert wird (also die lokale Datei neuer ist als die Remote), _lädt_ der s3-Sync die Datei herunter!

Ich konnte das nicht verstehen, also habe ich in den Dokumenten nachgesehen, welcher Zustand (bei der Beschreibung der Option --exact-timestamps ):

Das Standardverhalten besteht darin, Elemente gleicher Größe zu ignorieren, es sei denn, die lokale Version ist neuer als die S3-Version.

Die Verwendung von --exact-timestamps für den Download funktioniert wie erwartet (jeder Unterschied in den Zeitstempeln führt zu einer Kopie), aber dieser Standard erscheint mir rückwärts.

Anstatt "funktioniert wie geplant" zu sagen, hätte ich vielleicht "funktioniert wie dokumentiert" sagen sollen.

@jam13 Wow, das ist so seltsam, und ich dachte, es sei eine Verwirrung in der Dokumentation!
Aber wenn dies die neue Art ist, Fehler zu beheben, indem Sie sie einfach explizit in die Dokumentation aufnehmen ...

@jam13

Ich bin mir nicht sicher, ob wir ein Zeitzonenproblem ausschließen können.
Jeden Tag, wenn ich die erste Änderung in der s3-Konsole vornehme und aws s3 sync s3://$BUCKET . synchronisiere, wird es synchronisiert. Wenn ich eine weitere Änderung an der Datei vornehme und dann synchronisiere, wird sie nicht synchronisiert.
Aber es funktioniert am nächsten Tag.

Das lässt mich überdenken, ob es an der Zeitzone liegen könnte.

Überprüfen Sie also ein wenig mehr über den Befehl touch -m , den Sie oben erwähnt haben.

touch -m -t 201901010000 test/local/test.json
Wenn die Änderungszeit der Datei auf letztes Jahr geändert wird, lädt die s3-Synchronisierung die Datei immer noch nicht herunter, sodass es sich nicht nur um ein Zeitzonenproblem handelt.

Der obige Touch-Befehl datiert nur die mtime zurück. Es kann (und kann) die ctime nicht rückdatieren.
Benutzt die S3 cli vielleicht die 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

Ich denke, Dateisynchronisierungen sollten die Dateien lokal garantieren und remote gleich sind. Ich finde es nicht unfair, das zu sagen. Ich denke, aws s3 sync ist eher ein update als eine Synchronisierung. Ich werde jetzt jede Implementierung von aws s3 sync in aws s3 cp --recursive ändern.

Danke @jam13 für die Erklärung unter https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439