Plutôt que de stocker le cache des ETags fournis par le serveur, l'ETag peut-il être calculé côté client ? Ensuite, ce serait presque comme faire des vérifications md5, mais en utilisant les données disponibles dans la réponse ListObjects. Tant que l'algorithme ETag ne repose pas sur l'état côté serveur…

Ah : https://forums.aws.amazon.com/thread.jspa?messageID=203510&state=hashArgs%23203510

Tu l'as trouvé :-)

-- Seb

Le 17 janvier 2014, à 16h26, Jeff Waugh < [email protected] [email protected] > a écrit :

Ah : https://forums.aws.amazon.com/thread.jspa?messageID=203510&state=hashArgs%23203510

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/aws/aws-cli/issues/599#issuecomment -32668382.

Amazon EU Societe a responsabilite limitée, 5 Rue Plaetis, L - 2338 Luxembourg, RCS Luxembourg n B 101818, capital social : 37.500 EUR. Autorisation d'établissement en qualité de commercante n 104408.

Oui, nous ne pouvons pas calculer de manière fiable l'ETag pour les téléchargements en plusieurs parties, sinon ce serait une excellente solution.

Pourriez-vous ajouter un nouveau drapeau (ou 2) pour le comportement temporel ? Peut-être --check-timestamps pour l'option 1 et --update-local-timestamps pour l'option 2. De cette façon, l'utilisateur peut spécifier une vérification plus robuste des modifications et accepter les conséquences en même temps.

Oui, je pense que l'ajout de drapeaux pour les options 1 et 2 serait une approche raisonnable. Une préoccupation potentielle est que le comportement par défaut (aucune option spécifiée) a des cas où sync ne se comporte pas comme on pourrait s'y attendre, mais je ne suis pas sûr que changer le comportement par défaut pour l'une de ces options soit une bonne chose ici, étant donné les compromis potentiels que nous ferions.

@jamesls J'utilise la commande sync pour déployer un site Web statique généré.

Avec la version actuelle, je recharge tous les fichiers à chaque synchronisation car le mtime change lorsque le site est régénéré, même si le contenu ne le fait pas.

Pour mes besoins (et j'imagine qu'un bon nombre d'autres personnes utilisent cet outil fabuleux pour télécharger leurs sites statiques), la synchronisation via ETag comme suggéré dans #575 serait des plus géniales, mais compte tenu de ma lecture de ce problème, cela ne semble pas être le cas. une option.

À moins que, pour les besoins des sites statiques, une vérification de la longueur uniquement (bien que peut-être légèrement dangereuse) fonctionnerait.

Une autre option serait pour nous de désactiver les téléchargements en plusieurs parties et d'utiliser #575 - nous verrions d'énormes économies immédiatement.

J'ai trouvé le problème inverse. J'ai modifié un fichier dans S3 qui a la même taille mais un horodatage plus récent et la synchronisation s3 ne le tire pas vers le bas

aws s3 sync s3://bucket/path/ dir

En regardant les données dans S3 ... Je pense que c'est à cause de problèmes de fuseau horaire.
Les Propriétés affichent un temps de

Dernière modification : 21/02/2014 10:50:33 AM

Mais les en-têtes HTTP montrent

Dernière modification : ven. 21 février 2014 15:50:33 GMT

Notez que la propriété Dernière modification n'affiche pas le fuseau horaire ?

Étant donné que ma commande de synchronisation s3 s'exécute sur un serveur différent avec un fuseau horaire différent de celui où j'ai placé le fichier, il pense que le fichier est dans le passé et ne le tire pas.

J'ai dû passer à s3 cp pour m'assurer qu'il récupère tous les fichiers

Je pense que dans un premier temps, nous devrions implémenter l'argument --size-only . Cela ne résout pas le problème dans le cas général, mais pour certains scénarios, cela aidera et c'est facile à comprendre/expliquer, en particulier le cas d'utilisation référencé ci-dessus avec des sites statiques synchronisés avec s3.

Je pense que la synchronisation devrait avoir une option pour toujours synchroniser les fichiers si le fichier à synchroniser est plus récent que la cible. Nous synchronisons les fichiers de la machine A vers S3 et ensuite de S3 vers la machine B. Si la taille d'un fichier ne change pas (mais le contenu le fait), ce fichier n'atteindra pas la machine B. Ce comportement est cassé. Je me fiche de savoir si je synchronise avec beaucoup de fichiers, mais les fichiers modifiés ne doivent jamais être laissés de côté.

Comme dans mon message précédent, "plus récent" doit également prendre en compte le fuseau horaire.
Actuellement, ce n'est pas le cas si vous transférez un fichier vers S3 à partir d'un fuseau horaire puis que vous le synchronisez à partir d'un autre, il ne détectera pas correctement que le fichier est plus récent.

@jamesls En plus de l'argument --size-only, je serais intéressé par l'utilisation d'un argument --name-only. Autrement dit, ne vérifiez ni la taille du fichier ni l'heure de la dernière modification. Copiez simplement les fichiers qui existent dans la source mais pas dans la cible. Dans notre scénario, nous synchronisons de s3 à local et une fois que nous avons téléchargé un fichier, nous ne nous attendons pas à ce qu'il change sur s3. Si cette option résultait en moins d'opérations sur notre système de fichiers local (nfs), cela pourrait entraîner une amélioration des performances.

@jamesls Est-ce que --size-only et al devraient être disponibles en 1.3.6 ?

Mon représentant AWS Support pour le cas 186692581 dit qu'il vous a transmis ma suggestion.
J'ai pensé que je le posterais ici de toute façon pour commenter:

Je pense qu'une solution simple serait d'introduire un facteur de fuzz.
Si cela ne prend normalement pas plus de 5 minutes pour la copie locale -> S3,
puis utilisez un facteur de flou de 10 minutes sur les comparaisons de temps suivantes.
Traitez les temps relatifs dans les 10 minutes comme étant égaux.
Si l'heure S3 est plus récente de plus de 10 minutes, alors synchronisez depuis S3 -> local.
Peut-être ajouter "--fuzz=10m" en option.

@jamesls @adamsb6
https://github.com/aws/aws-cli/pull/575 ne serait-il pas une bonne option au moins pour les fichiers téléchargés en une seule partie ?

Si vous vérifiez le format ETAG du fichier sur S3, vous pouvez différer selon que le fichier a été téléchargé en un seul ("ETAG = "MD5 Hash") ou en plusieurs parties (ETAG = "MD5 Hash" - "Number of Parts"). pourrait comparer tous les fichiers locaux MD5 à leur ETAG et dans le cas où un fichier a été téléchargé en plusieurs parties, vous pouvez l'ignorer.

Nous avons un client qui a beaucoup de clips vidéo dans certains dossiers d'un compartiment S3, qui sont synchronisés avec les instances ec2 dans toutes les régions AWS. Tous les fichiers sont téléchargés en une seule partie.
Au moment où nous avons un problème dû à s3cmd, dans certains cas, certains fichiers sont corrompus. Si nous effectuons à nouveau une synchronisation complète, nous aurons 14 To de trafic qui seront facturés.

Notre problème : les fichiers corrompus ont exactement la même taille que le fichier d'origine sur s3 et en raison d'horodatages erronés via s3cmd, nous ne pouvons pas utiliser les options mentionnées ci-dessus. Dans ce cas, le --compare-on-etag serait une excellente solution pour éviter de synchroniser à nouveau tous les fichiers.

Même pour une synchronisation normale, l'option --compare-on-etag serait géniale, si vous n'avez que des fichiers téléchargés en une seule partie, car aws s3 sync ne synchronisera que les fichiers modifiés.

Je viens de passer la majeure partie de 3 heures à essayer de trouver les autorisations minimales requises pour utiliser la commande de synchronisation. L'erreur que j'obtenais était :
A client error (AccessDenied) occurred when calling the ListObjects operation: Access Denied

Quand vraiment l'erreur aurait dû être:
A client error (AccessDenied) occurred when calling the ListBucket operation: Access Denied

Un élément d'aide qui affiche un tableau avec les autorisations minimales pour chaque commande serait _très_ utile.

404 semble être une _très bonne idée_, vu que jusqu'à ce que je lise, je pensais que la synchronisation l'avait déjà fait.

Edit : pour clarifier, ajoutez un comportement similaire à rsync à "aws s3 sync". Il semble que ce problème tel qu'il a été signalé n'est pas tout à fait ce que j'avais initialement compris.

Étant donné que le dernier AWS-CLI-bundle.zip ne contient pas le correctif implémenté ci-dessus, j'ai fait un clone git. Je peux voir le nouveau code dans un dossier appelé "personnalisations". Cependant, il n'est pas clair pour moi comment créer une commande aws-cli à l'aide de ce code. Dois-je exécuter make-bundle ?

Ouais. J'utilise les étapes suivantes pour l'installer sur de nouveaux serveurs (Ubuntu) :

git clone https://github.com/andrew512/aws-cli.git
cd aws-cli
pip install -r requirements.txt
sudo python setup.py install

D'ACCORD.
Je vois le code modifié dans la version 1.3.18.
Il accepte mon paramètre --exact-timestamps.
Je pensais que le dernier bundle de téléchargement que j'avais précédemment installé était 1.3.21.

Un contrôle de version fiable ne s'appliquera vraiment qu'aux versions officielles d'AWS. J'ai créé le dépôt à la 1.3.18, c'est donc la version qu'il rapportera, mais il y a déjà quelques versions obsolètes, la 1.3.22 étant la plus récente pour le moment. Espérons qu'AWS accepte la demande d'extraction et inclue la fonctionnalité dans les futures versions officielles. Cela nous a été très précieux et aide à résoudre un comportement par défaut assez discutable.

@ andrew512 Désolé pour le retard. Je pense que le PR que vous avez envoyé est une bonne idée, et c'est vraiment utile d'avoir les commentaires des clients sur les aws s3 sync changements qui fonctionnent pour eux et ceux qui ne le font pas. Je vais jeter un oeil sous peu.

Je pense que... pour ceux d'entre nous qui ne craignent pas les demandes d'en-tête, la comparaison sur MD5 devrait être une option. Je voterais (deuxièmement) pour le -- compare-on-etag car je ne mets à jour que d'un serveur vers S3 -- et donc un référentiel MD5 local n'est pas un problème pour moi. MAIS je pense vraiment que nous devons avoir quelque chose. En l'état, je ne suis JAMAIS sûr que mes dépôts locaux et S3 sont les mêmes. Où en sommes-nous sur le statut de quelque chose comme ça?

@janngobble +1

Notre cas d'utilisation est que nous avons ces fichiers dans un dépôt git et ce sont des fichiers de configuration, donc ni la date modifiée ni la taille du fichier ne fonctionnent vraiment, nous aimerions donc voir une option md5 réelle pour ceux qui peuvent gérer les implications en termes de performances.

En effet, lorsque vous extrayez un dépôt git, la date de modification du fichier correspond au moment où le fichier est écrit. De plus, la taille du fichier ne fonctionne pas car le changement de fichier peut être quelque chose comme :

foo="bar"

à

foo="baz"

donc le fichier ne changerait pas de taille.

@jamesls Pourquoi ne pouvez-vous pas utiliser la méthode ici pour calculer le md5 pour les téléchargements en plusieurs parties ? Cela a fonctionné pour moi.

Bonjour,
J'ai aussi ce problème bien décrit avec foo="bar"/foo="baz".
J'utilise le compartiment S3 pour le déploiement de mon application et tous les serveurs se synchronisent à partir de S3 lorsqu'un déploiement est terminé. J'ai eu quelques fois le problème d'un opérateur >= changé en <= dans un fichier non synchronisé à cause de ce bug et pour moi la commande de synchronisation n'est pas très fiable à cause de ce bug. La taille est la même mais le contenu est différent, le fichier doit être synchronisé.
Je n'ai pas de conseil particulier sur la façon de le faire, désolé pour ça, mais j'expose juste mon usecase :)

Allez comprendre, j'ai rencontré le même problème lors du développement de node-ftpsync. J'ai supposé qu'AWS aurait une solution magique pour résoudre ce problème.

1. C'est chiant mais c'est nécessaire. Une comparaison mtime.equals est le moyen le plus rapide/le plus sale de détecter un changement. Malheureusement, les temps d'horloge entre les hôtes locaux et distants doivent être normalisés avant de pouvoir être comparés.

C'est probablement une bonne idée de le "fuzz" (c'est-à-dire en arrondissant aux 10 minutes les plus proches) comme @ngbranitsky l'a suggéré. Le faire dans node.js est pénible, mais en python, cela devrait être aussi simple que de tronquer les derniers bits à l'aide d'un AND au niveau du bit.

1. Peut fonctionner, avec des effets secondaires. J'ai également exploré cette option en modifiant éventuellement le mtime local pour qu'il corresponde à la valeur MDTM (c'est-à-dire FTP mtime) du serveur. Malheureusement, les implémentations de serveur FTP sont rarement conformes aux RFC et peuvent ne pas inclure MDTM. Par exemple, la synchronisation de fichiers via FTP est nulle car il n'y a aucune garantie que le client et le serveur soient complets.

Comme AWS n'a pas ce problème, vous devez également considérer comment mtime est utilisé sur l'hôte local. En modifiant la valeur mtime à chaque synchronisation, allez-vous déclencher un événement de mise à jour en masse si des transpileurs surveillent ces fichiers ? Existe-t-il d'autres magasins de métadonnées qui utilisent mtime comme métrique pour mesurer les modifications apportées aux fichiers ?

1. Est la meilleure option si vous ne tenez pas compte du coût. Les appels d'API supplémentaires entraînent un coût pour les utilisateurs (c'est-à-dire un coût monétaire). Le MD5 ne sera nécessaire que pour les ajouts de fichiers et les fichiers modifiés, mais pour les utilisateurs stockant BEAUCOUP de petits fichiers et/ou des fichiers qui changent fréquemment, il peut s'additionner.
2. Est de loin la meilleure option pour assurer la cohérence, mais aussi la plus grande difficulté à mettre en œuvre.

Je me rends compte que ce n'est pas une solution générale, mais ce serait très bien de voir le comportement facultatif suivant pour la synchronisation, imo. C'est un peu comme non. 4 dans l'OP, uniquement modifié pour de meilleures performances.

1. Un cache local d'etags est conservé pour le système de fichiers local, et éventuellement le serveur si aucune modification hors bande des fichiers du compartiment ne peut être garantie par l'utilisateur.
2. Lors de la synchronisation local->serveur, un premier passage utilisant la comparaison mtime/taille par rapport à la base de données de cache est utilisé pour déterminer les modifications potentielles dans les fichiers locaux. (Ceci est fait pour éviter de recalculer inutilement le md5 qui est cher par rapport à fstat.)
3. Pour l'ensemble potentiellement modifié, le md5->etag est recalculé. Si le fichier est réellement différent, il est téléchargé. La base de données du cache local est mise à jour dans tous les cas pour éviter de recalculer le md5 sur les fichiers locaux.

Le cas d'utilisation ici est la synchronisation des tuiles de carte Web, dont <1% changent normalement quotidiennement. L'exception est lorsque des suppressions se produisent dans les données source qui modifient la couverture spatiale des tuiles, ce qui nécessite la régénération de l'ensemble des tuiles de la carte.

Le problème est le volume même impliqué. Je vois la discussion sur les gros téléchargements en plusieurs parties comme un cas d'utilisation, mais pas sur de nombreux petits fichiers individuels. Combien de? Nous avons ~2m actuellement, mais cela peut devenir bien pire. Par exemple, au niveau de zoom 16, le monde a 1 << 16 x 1 << 16, ou 65536 x 65536 tuiles, ou ~4b.

Les options actuelles sont :

1. Synchronisez avec aws-cli normalement, en retéléchargeant tout.
   
   
   
   1. C'est le plus rapide dans l'ensemble.
   
   
   2. Hélas, de nombreux téléchargements inutiles se produiront.
   
   
2. Synchronisez avec s3cmd, qui utilise md5 (etag) plutôt que mtimes. Malheureusement:
   
   
   
   1. Il recalcule toujours le md5 pour chaque fichier local à chaque exécution, ce qui est relativement coûteux et génère beaucoup d'IOPS.
   
   
   2. Il est monothread et lié à la mémoire, et bien que toujours lent, il est particulièrement lent pour télécharger de nombreux fichiers individuels, en particulier en cas de latence plus élevée vers d'autres régions S3.
   
   

Je pourrais écrire du code C sans trop de difficulté qui parcourrait un chemin de répertoire, mettrait à jour une base de données de cache sqlite3 locale et créerait la file d'attente d'ensemble / téléchargement potentiellement modifiée. Malheureusement, je n'ai aucune expérience en python et je ne peux pas soumettre cela en tant que demande d'extraction pour un comportement de synchronisation facultatif.

Je ne sais pas à quel point le cas d'utilisation "beaucoup de petits fichiers, aucun changement hors bande garanti, local-> serveur uniquement" est courant.

Je trouve peu intuitif et dangereux que la synchronisation traite une différence dans les derniers temps modifiés comme une raison de mise à jour, même si un fichier plus récent à la source remplace un ancien à la destination. Ce comportement étrange doit être documenté.

Également lié au #404.

Qu'en est-il de l'ajout d'un seul indicateur --sync-if auto-documenté au lieu du nombre croissant d'options non auto-documentées ? (par exemple --size-only , --exact-timestamps . Puis-je appliquer ces deux en même temps ? Pourquoi dois-je lire la documentation/les essayer pour comprendre cela ?).

Le --sync-if pourrait avoir une liste d'options :

--sync-if newer-timestamp,different-md5,different-timestamp,different-size,deleted,...

L'utilisateur peut en spécifier un ou plusieurs (liste séparée par des virgules) et si le fichier répond à l'un des critères, il sera mis à jour (téléchargé/supprimé) à la destination.

Cela clarifierait grandement le comportement, surtout si vous aviez mentionné dans la documentation que le comportement par défaut est : --sync-if different-timestamp,different-size .

En lisant ce problème, je ne peux pas savoir si ce comportement de synchronisation a encore été corrigé.

Je veux quelque chose qui fonctionne aussi simplement que rsync -avz pour synchroniser ma version locale avec celles du serveur.

J'avais utilisé aws s3 sync , mais parce que j'ai un fichier qui est volumineux (un fichier d'aide qui est un film) et que mon étape de construction crée tous les fichiers à partir de nouveaux, il copie tous les fichiers à chaque fois et était inutilement lent à mettre à jour le site.

J'ai ensuite commencé à utiliser --size-only pour l'accélérer. Malheureusement, cela m'a mordu dans le cul récemment. J'avais renommé un fichier et l'étape de construction inclut une liste de fichiers dans le fichier service-worker.js afin que le sw sache quoi mettre en cache. Malheureusement, le nouveau et l'ancien nom de fichier avaient la même longueur, il n'a donc pas mis à jour le fichier service-worker.js et a continué à donner un 404 pour l'ancien nom de fichier. Il m'a fallu un certain temps pour comprendre ce qui se passait.

Il semble que ce soit un problème résolu dans d'autres environnements - c'est-à-dire par rsync - bien que, tbh, je suis probablement quelque peu ignorant des défis présentés par faire quelque chose comme ça sur S3. Quoi qu'il en soit, ayant été mordu par cela récemment, je regarde d'autres clients, mais ils semblent avoir des dépendances que je ne suis pas intéressé à adopter uniquement pour cette fonctionnalité.

Ce serait bien d'avoir une option de synchronisation etag. Je sais qu'il y a des scénarios où cela échoue, mais pour moi, ce serait super précieux.

Bonjour!

Nous fermons ce problème ici sur GitHub, dans le cadre de notre migration vers UserVoice pour les demandes de fonctionnalités impliquant l'AWS CLI.

Cela nous permettra de vous fournir les fonctionnalités les plus importantes, en facilitant la recherche et la prise en charge des fonctionnalités qui vous intéressent le plus, sans diluer la conversation avec des rapports de bogues.

En guise d'introduction rapide à UserVoice (s'il n'est pas déjà familier) : une fois qu'une idée est publiée, les gens peuvent voter sur les idées et l'équipe produit répondra directement aux suggestions les plus populaires.

Nous avons importé des demandes de fonctionnalités existantes depuis GitHub - Recherchez ce problème là-bas !

Et ne vous inquiétez pas, ce problème existera toujours sur GitHub pour la postérité. Comme il s'agit d'une importation de texte uniquement du message d'origine dans UserVoice, nous garderons toujours à l'esprit les commentaires et les discussions qui existent déjà ici sur le problème GitHub.

GitHub restera le canal pour signaler les bogues.

Encore une fois, ce problème peut maintenant être trouvé en recherchant le titre sur : https://aws.uservoice.com/forums/598381-aws-command-line-interface

-L'équipe des SDK et outils AWS

Cette entrée se trouve spécifiquement sur UserVoice à l' adresse :

https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168808-aws-s3-sync-issues

S'éloigner des problèmes de github ? Cela semble être une erreur...

D'accord. Cela ressemble plus à la méthode utilisée par Microsoft pour juger de l'importance/de l'impact des problèmes, mais je trouve cela assez irritant.

Sur la base des commentaires de la communauté, nous avons décidé de renvoyer les demandes de fonctionnalités aux problèmes GitHub.

Remonter ça !

Jusqu'au sommet!

la comparaison de md5 serait géniale, j'ajouterais également qu'il serait utile de sortir md5 lors du téléchargement ou du téléchargement. cela pourrait être stocké dans notre propre base de données et aiderait à déterminer si la synchronisation est nécessaire via notre base de données pour limiter les demandes.

@jamesls Pourriez-vous commenter ce problème s'il vous plaît?
https://github.com/aws/aws-cli/issues/4460