Aws-cli: La synchronisation AWS S3 ne synchronise pas tous les fichiers

Vous pouvez éventuellement utiliser --exact-timestamps pour contourner ce problème, bien que cela puisse entraîner des téléchargements excessifs si vous téléchargez.

Pour aider à la reproduction, pourriez-vous m'obtenir des informations sur l'un des fichiers qui ne se synchronise pas ?

• Quelle est la taille exacte du fichier localement ?
• Quelle est la taille exacte du fichier dans S3 ?
• Quelle est la dernière heure modifiée localement ?
• Quelle est l'heure de la dernière modification dans S3 ?
• Le fichier local est-il un lien symbolique / derrière un lien symbolique ?

Exemple d'exécution de commande
aws s3 sync s3://bucket/ /var/www/folder/ --delete

Plusieurs fichiers sont manquants
Taille locale exacte : 2625
S3 exact : 2625
Horodatage exact local : 06-Jan-2017 9:32:31
Horodatage exact s3 : 20-juin-2017 10:14:57
fichier normal en S3 et local

Il y a plusieurs cas comme ça dans une liste d'environ 50 000 fichiers. Cependant, tous les manquants synchronisés sont différents le 20 juin 2017.

L'utilisation de --exact-timestamps montre beaucoup plus de fichiers à télécharger bien qu'ils soient exactement le même contenu. Cependant, il leur manque encore ceux de l'exemple ci-dessus.

même problème ici.
aws s3 sync dist/ s3://bucket --delete n'a pas téléchargé s3://bucket/index.html avec dist/index.html

dist/index.html et s3://bucket/index.html ont la même taille de fichier, mais leur temps de modification est différent.

en fait, parfois awscli a téléchargé le fichier, mais parfois non

Idem ici, --exact-timestamps n'aide pas - index.html n'est pas écrasé.

Nous avons bien connu ce problème aujourd'hui/la semaine dernière. Encore une fois, index.html a la même taille de fichier, mais le contenu et les heures de modification sont différents.

Est-ce que quelqu'un connaît une solution de contournement pour cela?

Je viens de tomber sur ça. Même problème que celui signalé par @icymind et @samdammers : le contenu de mon fichier index.html (local) avait changé, mais sa taille de fichier était la même que celle de la copie précédente dans S3. La commande {{aws s3 sync}} ne l'a pas téléchargé. Ma "solution de contournement" consistait à supprimer index.html de S3, puis à relancer la synchronisation (qui l'a ensuite téléchargée comme s'il s'agissait d'un nouveau fichier, je suppose).

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

Après aws s3 sync exécuté sur 270T de données, j'ai perdu quelques Go de fichiers. La synchronisation n'a pas du tout copié les fichiers avec des caractères spéciaux.

Exemple de fichier /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

J'ai dû utiliser cp -R -n

même problème ici fichier xml de la même taille mais un horodatage différent n'est pas correctement synchronisé

j'ai pu reproduire ce problème

bug.tar.gz
télécharger le fichier tar joint, puis

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

vous verrez que même si repomd.xml dans les répertoires a et b diffèrent par leur contenu et leur horodatage
essayer de synchroniser b ne fait rien

Testé le
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

je vois le même problème. essayer de synchroniser un répertoire de fichiers à partir de s3 où un fichier a été mis à jour vers un répertoire local. ce fichier n'est pas mis à jour dans le répertoire local

Je vois ça aussi. Dans mon cas, il s'agit d'une application de réaction avec index.html qui fait référence aux fichiers .js générés. Je les synchronise avec l'option --delete pour supprimer les anciens fichiers auxquels on ne fait plus référence. L'index.html n'est parfois pas téléchargé, ce qui entraîne un ancien index.html qui pointe vers des fichiers .js qui n'existent plus.

D'où mon site Web ne fonctionne plus !!!

Je ne comprends actuellement pas pourquoi cela se produit.

Quelqu'un a-t-il des idées ou des solutions de contournement ?

Nous avons le même problème, mais nous venons de trouver une solution de contournement. Je sais, ce n'est pas la meilleure façon, mais ça marche :

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

Il nous semble que la copie fonctionne bien, donc d'abord, nous copions, puis nous utilisons la commande sync pour supprimer les fichiers, qui ne sont plus présents.
J'espère que le problème sera résolu au plus vite.

J'ai ajouté --exact-timestamps à mon pipeline et le problème ne s'est pas reproduit. Mais, c'était intermittent en premier lieu, donc je ne peux pas être sûr que cela l'ait réparé. Si cela se reproduit, je vais suivre la suggestion de @marns93 .

Nous avons rencontré ce problème et --exact-timestamps résout notre problème. Je ne sais pas si c'est exactement le même problème.

Je vois ce problème, et c'est très évident car chaque appel ne doit copier qu'une poignée (moins d'une douzaine) de fichiers.

La situation dans laquelle cela se produit est exactement comme indiqué ci-dessus : si le dossier dans lequel sync ajouté contient un fichier avec un contenu différent mais une taille de fichier identique, sync ignorera la copie du nouveau fichier mis à jour à partir de S3.

Nous avons fini par changer les scripts en aws s3 cp --recursive pour le corriger, mais c'est un bogue désagréable -- pendant très longtemps, nous avons pensé que nous avions une sorte de condition de concurrence dans notre propre application, sans réaliser qu'aws-cli était simplement choisir de ne pas copier le(s) fichier(s) mis à jour.

J'ai vu ça aussi avec un fichier html

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

J'ai copié-collé la commande s3 sync partir d'un GitHub et --size-only défini. Supprimer cela a résolu le problème !

Je viens de rencontrer ce problème avec des artefacts de build téléchargés dans un bucket. Notre code HTML avait tendance à ne changer que les codes de hachage pour les liens d'actifs et la taille était donc toujours la même. La synchronisation S3 les ignorait si la construction était trop tôt après une précédente. Exemple:

10:01 - Build 1 s'exécute
10:05 - Construire 2 pistes
10:06 - Build 1 est téléchargé sur s3
10:10 - Build 2 est téléchargé sur s3

La version 2 contient des fichiers HTML avec un horodatage de 10:05, mais les fichiers HTML téléchargés sur s3 par la version 1 ont un horodatage de 10:06 car c'est à ce moment-là que les objets ont été créés. Il en résulte qu'ils sont ignorés par la synchronisation s3 car les fichiers distants sont "plus récents" que les fichiers locaux.

J'utilise maintenant s3 cp --recursive suivi de s3 sync --delete comme suggéré précédemment.

J'espère que cela pourra être utile à quelqu'un.

J'ai eu le même problème plus tôt cette semaine; Je n'utilisais pas --size-only . Notre index.html était différent d'un seul caractère ( . est passé à # ), donc la taille était la même, mais l'horodatage sur s3 était 40 minutes plus tôt que l'horodatage du nouvel index .html. J'ai supprimé le fichier index.html comme solution de contournement temporaire, mais il est impossible de revérifier chaque déploiement.

La même chose ici, les fichiers portant le même nom mais avec un horodatage et un contenu différents ne sont pas synchronisés de S3 vers local et --delete n'aide pas

Nous vivons le même problème. Un index.html avec la même taille mais un horodatage plus récent n'est pas copié.

Ce problème a été signalé il y a plus d'un an. Pourquoi n'est-il pas corrigé ?

En fait, cela rend la commande snyc inutile.

heure exacte

--exact-timestamps a résolu le problème

Je suis également affecté par ce problème. J'ai ajouté --exact-timestamps et le problème semblait résoudre les fichiers que je regardais. je n'ai pas fait une recherche exhaustive. J'ai de l'ordre de 100 000 fichiers et 20 Go, beaucoup moins que les autres ici.

J'ai rencontré le même problème, aws s3 sync ignorer certains fichiers, même avec des contenus différents et des dates différentes. Le journal montre que ces fichiers ignorés sont synchronisés mais en fait pas.
Mais lorsque j'exécute à nouveau aws s3 sync , ces fichiers ont été synchronisés. Très étrange!

J'ai eu ce problème lors de la création d'un site avec Hugo et je l'ai finalement compris. J'utilise des sous-modules pour mon thème Hugo et je ne les tirais pas sur CI. Cela provoquait des avertissements dans Hugo mais pas des échecs.

# 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  

Une fois que j'ai mis à jour les sous-modules, tout a fonctionné comme prévu.

Nous avons également été affectés par ce problème, à tel point qu'une plate-forme est tombée en panne pendant environ 18 heures après qu'un nouveau fichier vendor/autoload.php n'ait pas été synchronisé et était obsolète avec vendor/composer/autoload_real.php donc l'ensemble de l'application n'a pas pu se charger.

C'est un problème _très_ étrange, et je ne peux pas croire que le problème soit ouvert depuis si longtemps.

Pourquoi une synchronisation n'utiliserait-elle pas les hachages au lieu de la dernière modification ? N'a aucun sens.

Pour les futurs Googleurs, une erreur rédigée que je recevais :

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

Le même problème, tous les fichiers ne sont pas synchronisés, --exact-timestamps n'a pas aidé.

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

Je n'arrive pas à croire que ce ticket soit ouvert si longtemps... même problème ici, où est l'obsession client d'Amazon ?

Je ne peux pas croire que ce ticket n'a pas été fermé il y a quelque temps. Pour autant que je sache, cela fonctionne comme prévu, mais les utilisateurs (y compris moi) font des hypothèses sur la façon dont cela devrait fonctionner et sont ensuite surpris lorsqu'il ne se comporte pas comme ils l'attendaient.

• Lorsqu'un fichier est synchronisé ou copié _vers_ s3, l'horodatage qu'il reçoit sur le compartiment correspond à la date à laquelle il a été copié, qui est _toujours_ plus récente que la date du fichier source. C'est ainsi que fonctionne s3.
• Les fichiers ne sont synchronisés que si la taille change ou si l'horodatage de la cible est _plus ancien_ que la source.
• Cela signifie que si les fichiers source sont mis à jour mais que la taille des fichiers reste inchangée et que les dates de ces fichiers modifiés sont antérieures à leur dernière copie, s3 sync ne les synchronisera pas à nouveau.
• L'utilisation de --exact-timestamps _only_ fonctionne lors de la copie de s3 vers local. Il n'est délibérément pas activé pour local à s3 car les horodatages sont _jamais_ égaux. Donc, le définir lors de la synchronisation de local à s3 n'a aucun effet.
• Je ne pense pas que s3 calcule les hachages pour les fichiers téléchargés, il n'y a donc aucun moyen d'éviter la taille du fichier et la dernière date de téléchargement comme vérifications.

L'essentiel est que cela fonctionne comme prévu, mais il existe divers cas d'utilisation où cela n'est pas souhaitable. Comme mentionné ci - s3 cp --recursive

@ jam13 merci pour l'explication, maintenant tout a du sens avec le recul !

Néanmoins, je dirais que c'est actuellement mal documenté (je m'attendrais à un gros avertissement rouge dans la documentation indiquant que --exact-timestamps ne fonctionne que _de s3 à local_ et aussi pour que la cli s3 se renfloue au lieu de silencieusement en ignorant le paramètre) et un mode de comparaison facultatif basé sur le hachage est nécessaire pour mettre en œuvre un mode de synchronisation fonctionnant de manière fiable.

Oui, la documentation n'est pas géniale, et ignorer les options en silence est très inutile. L'absence de toute direction ou même de commentaires officiels sur ce ticket de la part d'AWS au cours des 2 dernières années en dit également long.

@ jam13 J'ai creusé dans certaines documentations et j'ai découvert que j'avais besoin de --exact-timestamps pour contourner certains problèmes de s3 à local. Merci!

@kyleknap @KaibaLopez @stealthycoin une mise à jour sur celui-ci ?

Je ne peux pas croire que ce ticket n'a pas été fermé il y a quelque temps. Pour autant que je sache, cela fonctionne comme prévu, mais les utilisateurs (y compris moi) font des hypothèses sur la façon dont cela devrait fonctionner et sont ensuite surpris lorsqu'il ne se comporte pas comme ils l'attendaient.

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

L'essentiel est que cela fonctionne comme prévu, mais il existe divers cas d'utilisation où cela n'est pas souhaitable. Comme mentionné ci - s3 cp --recursive

s3 hache les objets, mais pas d'une manière entièrement connue si vous n'êtes pas le téléchargeur , et stocke cela sous le nom ETag familier. Le problème est que l'ETag dépend du nombre de morceaux et de la taille des morceaux utilisés lors du téléchargement du fichier. Si vous n'êtes pas le téléchargeur, vous ne connaissez probablement pas la taille du morceau (mais pouvez obtenir le nombre de morceaux à partir de l'ETag). Je ne sais pas pourquoi c'est fait de cette façon.

Cela fonctionne probablement comme prévu, mais ne fonctionne pas comme il se doit. Il devrait être trivial de vérifier si un fichier a changé

C'est juste un énorme piège pour que les gens expérimentent de manière inattendue une désynchronisation
Les données. Il existe 100 solutions de contournement différentes qui pourraient sauver tout le monde ici
le temps de lecture de ce billet, ainsi que le temps passé à découvrir ce
était un problème dans leur code source. Pourquoi ne peuvent-ils pas en faire un ?

Le mar. 14 avril 2020 à 13:57 Keith Kelly [email protected]
a écrit:

Je ne peux pas croire que ce ticket n'a pas été fermé il y a quelque temps. Autant que je peux
dire, cela fonctionne comme prévu, mais les utilisateurs (y compris moi) font des suppositions sur
comment cela devrait fonctionner et sont ensuite surpris quand il ne se comporte pas comme ils
attendu.

• Lorsqu'un fichier est synchronisé ou copié _vers_ s3, l'horodatage qu'il reçoit sur le compartiment correspond à la date à laquelle il a été copié, qui est _toujours_ plus récente que la date du fichier source. C'est ainsi que fonctionne s3.

• Les fichiers ne sont synchronisés que si la taille change ou si l'horodatage de la cible est _plus ancien_ que la source.

• Cela signifie que si les fichiers source sont mis à jour mais que la taille des fichiers reste inchangée et que les dates de ces fichiers modifiés sont antérieures à leur dernière copie, s3 sync ne les synchronisera pas à nouveau.

• L'utilisation de --exact-timestamps _only_ fonctionne lors de la copie de s3 vers local. Il n'est délibérément pas activé pour local à s3 car les horodatages sont _jamais_ égaux. Donc, le définir lors de la synchronisation de local à s3 n'a aucun effet.

• Je ne pense pas que s3 calcule les hachages pour les fichiers téléchargés, il n'y a donc aucun moyen d'éviter la taille du fichier et la dernière date de téléchargement comme vérifications.

L'essentiel est que cela fonctionne comme prévu, mais il existe divers cas d'utilisation
où ce n'est pas souhaitable. Comme mentionné ci-dessus
<#m_8540343689970969812_issuecomment-534061850> J'ai travaillé autour de cela
en utilisant s3 cp --recursive

s3 hache les objets, mais pas de manière entièrement connaissable
https://teppen.io/2018/10/23/aws_s3_verify_etags/ , et stocke ceci comme
le ETag familier https://en.wikipedia.org/wiki/HTTP_ETag . Le problème
est que l'ETag dépend du nombre de morceaux et de la taille des morceaux qui
le fichier a été téléchargé. Si vous n'êtes pas le téléchargeur, vous ne
connaître la taille du morceau (mais peut obtenir le nombre de morceaux de l'ETag). je
ne sais pas pourquoi c'est fait de cette façon.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...à M

A eu le même problème. Résolu en modifiant la stratégie du compartiment source en :

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

J'ai eu le problème avec cp --recursive et sync .
Cela a tout résolu. J'ai eu deux actions qui auraient dû très bien fonctionner, mais ne l'ont pas fait. Essayez-le et dites-moi si cela a résolu votre problème.

Sonner ici pour dire que j'ai également eu le problème avec sync . La seule raison pour laquelle j'ai remarqué, c'est parce que je scellais et MHL des deux sync ne fonctionnait pas, et il me manquait environ 60 Go sur 890 Go, en essayant de parcourir, dossier par dossier. Ensuite, j'ai trouvé ce fil et essayé cp --recursive et les données ont recommencé à circuler. Je vérifierai la MHL une dernière fois une fois que j'aurai le reste de ces données.

J'ai écrit un script pour reproduire le problème, j'utilise :
aws-cli/1.18.34 Python/2.7.17 Darwin/19.4.0 botocore/1.13.50

Si vous exécutez le script, vous verrez qu'après le téléchargement de la modification, la même modification n'est plus téléchargée. Voici le script :

#!/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 Veuillez lire la réponse @jam13 https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 avant — ce n'est pas un bug, c'est une fonctionnalité !

Merci pour l'astuce @applerom , mais je ne peux vraiment pas comprendre comment @jam13 le déclare comme "fonctionne comme prévu". Un outil de synchronisation doit être conçu pour garder la source et la destination égales, et cela n'est tout simplement pas donné avec cette synchronisation. Ce qui le rend inutile pour de nombreuses applications.

De plus, si la taille du fichier est inchangée mais que l'horodatage de la source est plus récent, aucune synchronisation n'a lieu, comme dans mon exemple de script.

Merci pour l'astuce @applerom , mais je ne peux vraiment pas comprendre comment @jam13 le déclare comme "fonctionne comme prévu". Un outil de synchronisation doit être conçu pour garder la source et la destination égales, et cela n'est tout simplement pas donné avec cette synchronisation. Ce qui le rend inutile pour de nombreuses applications.

De plus, si la taille du fichier est inchangée mais que l'horodatage de la source est plus récent, aucune synchronisation n'a lieu, comme dans mon exemple de script.

On dirait qu'il fait la mauvaise chose, n'est-ce pas.

J'ai effectué quelques autres tests pour voir ce que je devais faire pour que le téléchargement se produise :

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

Lorsque vous modifiez l'heure de modification du fichier à l'année dernière, la synchronisation s3 ne télécharge toujours pas le fichier, il ne s'agit donc pas simplement d'un problème de fuseau horaire.

Lors du changement de l'heure de modification sur maintenant (le fichier local est donc plus récent que le fichier distant), la synchronisation s3 _télécharge_ le fichier !

Je ne pouvais pas comprendre cela, alors j'ai vérifié les documents, qui indiquent (lors de la description de l'option --exact-timestamps ):

Le comportement par défaut consiste à ignorer les éléments de même taille, sauf si la version locale est plus récente que la version S3.

L'utilisation de --exact-timestamps pour le téléchargement fonctionne comme prévu (toute différence dans les horodatages entraîne une copie), mais cette valeur par défaut me semble en arrière.

Peut-être qu'au lieu de dire "fonctionne tel que conçu", j'aurais dû dire "fonctionne tel que documenté".

@ jam13 Wow, c'est tellement étrange, et j'ai pensé que c'était une confusion dans la documentation !
Mais si c'est la nouvelle façon de corriger les bugs, il suffit de les mettre explicitement dans la documentation...

@jam13

Je ne sais pas si nous pouvons exclure le problème de fuseau horaire.
Chaque jour, lorsque j'effectue le premier changement dans la console s3 et que je synchronise aws s3 sync s3://$BUCKET . , il se synchronise. Si j'apporte une autre modification au fichier, puis que je le synchronise, il ne se synchronise pas.
Mais ça marche le lendemain.

Cela me fait repenser si cela pouvait être à cause du fuseau horaire.

Vérifiez donc un peu plus la commande touch -m que vous avez mentionnée ci-dessus.

touch -m -t 201901010000 test/local/test.json
Lorsque vous modifiez l'heure de modification du fichier à l'année dernière, la synchronisation s3 ne télécharge toujours pas le fichier, il ne s'agit donc pas simplement d'un problème de fuseau horaire.

La commande tactile ci-dessus ne fait qu'antidater le mtime. Il n'antidate pas (et ne peut pas) le ctime.
Le cli S3 utilise-t-il peut-être le 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

Je pense que les synchronisations de fichiers devraient garantir les fichiers localement et à distance sont les mêmes. Je ne pense pas être injuste en disant cela. Je pense que aws s3 sync est plus un update , qu'une synchronisation. Je vais maintenant changer chaque implémentation de aws s3 sync en aws s3 cp --recursive .

Merci @jam13 pour l'explication sur https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439