Aws-cli: aws s3 sync ne synchronise pas la structure du dossier s3 localement

Ce comportement est connu. La raison pour laquelle la commande sync se comporte de cette façon est que s3 n'utilise pas physiquement les répertoires. Il n'y a que des buckets et des objets. Les objets ont des préfixes qui agissent comme des répertoires, mais s3 ne désigne pas un objet physique spécifique comme répertoire.

Par conséquent, lorsque la synchronisation se produit, seuls les fichiers sont transférés vers s3 car s3 n'a pas de répertoires physiques. Ainsi, lorsque vous essayez de synchroniser des répertoires vides, rien n'est téléchargé car ils ne contiennent aucun fichier. Une fois que vous avez placé des éléments dans le répertoire, le fichier (avec le préfixe représentant le répertoire) sera téléchargé.

Merci Kyle, c'est clair. Je sais comment S3 stocke les fichiers, mais parfois nous avons besoin de la même structure de répertoires à plusieurs endroits même s'il y en a des vides ou de les supprimer si nous n'en avons plus besoin.
Un bon exemple si vous avez une structure de répertoire complexe avec beaucoup de contenu localement que vous avez synchronisé avec S3. Après cela, un mécanisme automatisé synchronise périodiquement cette structure avec plusieurs instances en cours d'exécution. Vous maintenez à jour (supprimez) la plupart des contenus de S3, puis l'automatisme se resynchronise aux endroits où vous l'utilisiez auparavant. Malheureusement, vous constaterez que la structure de répertoires complexe d'origine reste pour toujours sur les cibles de synchronisation, ce qui peut prêter à confusion si vous souhaitez la vérifier ou si votre programme essaie d'utiliser ces dossiers vides car vous avez toujours besoin des mêmes partout. De plus, les personnes qui l'utilisent avec les options --delete utilisaient peut-être l'équivalent "rsync" auparavant sous Linux qui garde les dossiers synchronisés et compte donc sur la même opération.
Je pense qu'il ne serait pas difficile d'implémenter un commutateur ou une option pour que l'outil aws détecte d'une manière ou d'une autre si un objet S3 est un fichier ou un dossier (liste, taille, etc.) et les crée/supprime localement ou dans un compartiment S3 (par exemple list(bucket.list("", "/")) ?

Ça a du sens. Je vais envisager d'ajouter une fonctionnalité pour cela.

Cela serait également très utile pour notre situation. S'il était ajouté en option (--sync-empty-directories), les utilisateurs pourraient choisir de l'utiliser en cas de besoin.

+1 Besoin de cette fonctionnalité très mal

+1. Voudrais l'utiliser.

+1

J'ai également été surpris par ce comportement, étant donné qu'il s'appelle "sync".
Je peux contourner ce problème dans mon cas d'utilisation particulier, mais les futurs utilisateurs pourraient être épargnés :)

+1 pour pouvoir synchroniser la structure des répertoires ! Si vous supprimez un dossier, cela ne supprime que le contenu, mais il laisse le dossier derrière...

+1. J'ai les mêmes besoins.

+1 - surpris que cela n'ait pas encore été mis en œuvre. Bien sûr, dans mon cas, cela n'a pas trop d'importance et je peux contourner ce problème (ou simplement utiliser des fichiers d'espace réservé lors de la création de structures), mais ce serait un avantage de le prendre en charge par s3 sync ou s3 cp.

+1

s3cmd sync conserve la structure des dossiers, mais il y a donc quelques problèmes lors de l'octroi de l'accès lors de la synchronisation, il faut donc exécuter un autre s3cmd setacl --recursive par la suite…

+1

+1

+1

Merci pour les retours à tous. Je pense que la meilleure option que j'ai vue est d'ajouter une option --sync-empty-directories . Faisons cela.

@jamesls Je m'attends à des fonctionnalités similaires à rsync, mais s3 en tant que stockage d'objets n'est certainement pas le même.

+1

+1

Un calendrier pour cette fonctionnalité ?

Comme solution de contournement temporaire, j'ai ajouté un fichier .s3keep vide aux répertoires vides et cela fonctionne pour moi. C'est un hack que j'utilise habituellement pour tromper git afin qu'il ne traite pas les répertoires vides comme des répertoires vides :)

Cela permettra-t-il également de "supprimer/supprimer" les répertoires vides sur S3 ?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

_A beaucoup de sens lors des migrations de données vers s3._

+1

+1 Je viens de me faire écraser par ça... Arg....

+1

+10
Il est possible de contourner ce problème avec des fichiers factices, mais ce serait plus propre s'il y avait une option pour forcer un préfixe vide à se synchroniser.

+1. Cas d'utilisation : sauvegarde d'un référentiel svn.

Plus généralement:
chose de synchronisation aws s3
synchronisation aws s3chose_copie

Je m'attendais à ce que thing_copy corresponde exactement à la chose.

+1

+1

+1

+1 besoin de supprimer les répertoires vides

Comment progresse l'ajout de cette option --sync-empty-directories ?
des commentaires de l'équipe AWS ?
Merci.

+1 serait une fonctionnalité très utile pour un outil très utile

+1

+1 (moi aussi je souhaite que cette fonctionnalité soit implémentée et je souhaite que Github.com ait une interface de type StackOverflow.com pour "voter" sur les problèmes/fonctionnalités).

+1

+1

+1

+1

+1

2+ ans plus tard et cela ne s'est toujours pas produit.. ? le sera-t-il jamais ? =/

+1

+1

+1

+1

+1000

+1

J'ai fait quelques recherches sur la façon dont cela pourrait être mis en œuvre. Toutes les commandes s3 finissent par utiliser TransferManager de la bibliothèque s3transfer . ( référencé ici )

Pour prendre en charge l'ajout d'un dossier avec PutObject, nous pouvons envoyer une chaîne vide dans le paramètre Body. Je ne sais pas si cela est officiellement pris en charge. J'ai implémenté ça ici :
https://github.com/svleeuwen/s3transfer/commit/b7d3745a995a75c5262950bb798c8c57e481c2b3

J'aimerais avoir des commentaires à ce sujet de la part d'un responsable avant de continuer.

+1

ma solution consistait à monter mon bucket avec s3fs et rsync du montage s3 vers un répertoire de mon répertoire personnel.

+1

+1 vraiment besoin de ça...

+1

Ouvert depuis 2014 ? Vraiment? :pas amusé:

+1

+1

+1

+1

+1

+1

+1

+1

+1

@thenetimp Cette solution convient aux petits seaux. Nous utilisons un bucket avec plus de 15 To. S3FS devient horriblement lent avec des seaux plus gros.

+1

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 de la publication 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 à : https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not-synchronize-s3- structure-dossier

excellent travail Andre, fermez un problème et donnez-nous un lien qui n'est pas lié au problème. De tous les messages inutiles

Le passe-partout générique est décevant. Je pense que la frontière entre une demande de fonctionnalité et un rapport de bogue peut être assez floue. Pour éviter que les gens recherchent la publication UserVoice pour cette demande de fonctionnalité, ils sont disponibles sur https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168436-aws-s3-sync-does-not -synchronize-s3-folder-structu

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

+1

+1

+1

+1

+1

+1

+1. Ce serait une fonctionnalité intéressante à ajouter.

+1

+1

Même problème
awscli==1.16.74

+1

-1

La commande aws s3 sync est déjà récursive, il n'est donc pas nécessaire d'avoir une option récursive. De plus, la commande sync copie uniquement les éléments qui n'existent pas déjà sur la destination. Si vous pointez sur un dossier, il synchronisera de manière récursive tout ce qui n'existe pas déjà à l'intérieur sur votre destination cible. Ceci est différent de la commande aws s3 cp. La commande cp copie tout ce que vous lui dites, même s'il existe déjà sur la cible. La commande cp/mv/rb prend une option --recursive pour copier/déplacer/supprimer de manière récursive des dossiers/fichiers. Merci

@3ggaurav le problème date de 2014 lorsque je me souviens que sync avait une option --recursive .

De plus, si vous allez citer une réponse de débordement de pile textuellement, il est généralement recommandé de la référencer/d'y attribuer le crédit.

La réponse au débordement de la pile est ici.

Toujours pas de progrès à ce sujet ?

+1