Modifier les objets enfants

La modification des objets enfants applique les mêmes instructions aux objets d’un bucket ou d’un dossier logique, récursivement. Le dossier sélectionné n’est pas lui-même un objet enfant. Toutes les clés terminées par / et leurs versions sont ignorées, même si elles contiennent des données, quelles que soient les instructions et les règles d’inclusion. Les objets situés sous ces préfixes restent traités normalement. La commande peut combiner plusieurs types de changement.

Choisir la portée et préparer l’accès#

Dans le panneau S3, sélectionnez un seul bucket ou dossier logique courant. Sans Show versions, le menu propose Modify child objects… pour les objets courants. Avec Show versions, il propose Modify child object versions…, qui traite les versions courantes et non courantes et ignore les marqueurs de suppression.

Ce mode exige Object versions, les permissions de listing et au moins une modification applicable aux versions : ACL, tags ou chiffrement en place. Lorsque la lecture du versionnement est prise en charge pour le bucket avec Read bucket versioning, son état doit être confirmé activé ou suspendu. Sans cette lecture, un état local inconnu n’empêche pas le traitement ; un bucket connu comme n’ayant jamais eu le versionnement activé reste exclu. Sur Amazon S3, le listing exige s3:ListBucketVersions et la lecture d’état, lorsqu’elle est utilisée, s3:GetBucketVersioning.

Les filtres d’affichage du navigateur ne restreignent pas cette commande. Les instructions s’appliquent à toute la portée sous Location, après les filtres du dialogue. Un dossier historique ou un marqueur de suppression ne peut pas servir de racine.

Ouvrez File > Accounts…, sélectionnez le compte, cliquez sur Edit…, puis ouvrez Capabilities. Vérifiez les réglages suivants : ACL policy, Object tags, Storage classes, Encryption et Encryption policies doivent correspondre aux fonctions du service, au type de bucket et au traitement des objets courants ou des versions. Activer ces réglages ne crée aucune permission.

Les lectures et modifications demandent les permissions correspondant aux instructions : listing, lecture des propriétés ou du contenu pour une réécriture, lecture et écriture des ACL ou tags, écriture d’objet et accès aux clés KMS. Pour préserver Object Lock lors d’une réécriture, les permissions de lecture de rétention et de blocage légal, et celles nécessaires à leur conservation, peuvent être requises.

Pour changer le chiffrement sans copie, vérifiez Capabilities > Encryption > Update object encryption without copying, les permissions de mise à jour et les droits KMS décrits dans le chiffrement.

Comprendre les conséquences avant d’appliquer#

Les réécritures suivent les conditions des copies S3 du compte destination. Une condition source désactivée autorise la copie sans ce contrôle : le HEAD préalable ne garantit pas qu’une source mutable restera identique pendant sa réécriture. Les vérifications d’identité avant écriture restent actives.

Changer les métadonnées ou la classe de stockage réécrit les objets courants par copie. Lorsque le versionnement est activé, cela crée de nouvelles versions courantes et augmente le stockage conservé. Un objet archivé doit être accessible pour une copie ; une restauration peut être nécessaire.

Un changement de chiffrement compatible peut être appliqué en place sans copier les données. Sinon, les objets courants peuvent nécessiter une copie. Le traitement de versions précises utilise uniquement le changement en place pris en charge ; il n’offre pas les métadonnées ni la classe de stockage. Combiner un changement de chiffrement et une modification d’ACL est refusé en mode versions : exécutez-les dans des opérations séparées. Pour les objets courants, cette combinaison impose une copie et peut créer une nouvelle version, même si le chiffrement seul pourrait être modifié en place.

Les ACL et les tags peuvent être modifiés sans remplacer les données. Si vous demandez aussi une réécriture, ils sont appliqués à l’objet obtenu. Une lecture filtrée des ACL peut masquer certains droits ; l’interface demande votre accord si le changement risque de les retirer. Les règles de propriété du service déterminent le propriétaire de l’objet réécrit.

Une réussite partielle n’est pas annulée si une autre instruction échoue. Évitez de modifier les mêmes objets dans un autre client pendant le traitement.

Préparer les instructions#

1. Ouvrez la commande contextuelle correspondant au mode voulu.
2. Vérifiez Location et Apply to.
3. Configurez chaque page concernée ci-dessous ; les pages disponibles dépendent des capacités et du mode.
4. Ouvrez la rubrique Filters à gauche pour définir les filtres.
5. Ouvrez la rubrique Preview, puis cliquez sur Run preview sous la liste des résultats pour vérifier la sélection.
6. Cliquez sur Apply, puis acceptez les confirmations correspondant à la portée réelle.
7. Suivez l’opération et ses erreurs. Rouvrez les propriétés d’objets représentatifs après sa fin.

Au moins un changement valide est nécessaire. Les pages marquées (!) contiennent une valeur à corriger. Un changement de compte impose de fermer et rouvrir le dialogue.

ACL#

Keep unchanged, sélectionné au départ, ne demande pas de changement d’ACL.

Si une autre instruction réécrit le contenu, Keep unchanged demande la conservation de l’ACL lorsque les opérations ACL du compte sont activées ; cette conservation doit pouvoir être garantie. Si Enable ACL operations for this account est décoché, les modes de modification ACL sont indisponibles et la réécriture utilise le défaut de destination sans requête ni en-tête ACL. Keep unchanged ne garantit alors pas la conservation de l’ACL existante, même dans le même bucket. Les changements de métadonnées, classe et chiffrement restent possibles selon leurs propres prérequis. Voir les effets de la désactivation locale.

Pour un bénéficiaire, Add permissions ajoute les droits, Set permissions remplace ses droits, Remove permissions retire les droits choisis et Remove grantee le retire complètement. Choose grantee… permet de choisir un bénéficiaire connu. Canonical user attend un ID canonique ; S3 group attend le groupe autorisé ; Email (removal only) ne permet que de retirer un ancien bénéficiaire par e-mail.

Une seule instruction est autorisée par identité de bénéficiaire, avec au maximum 1 000 instructions. Une nouvelle instruction propose Add permissions, Canonical user et READ. Save this grantee in the account enregistre l’entrée après validation de l’instruction, ou dès validation du sélecteur dans Replace all grants ; annuler ensuite le dialogue principal ne retire pas cette entrée. Consultez les bénéficiaires et permissions ACL.

Les droits disponibles pour les objets comprennent READ, READ_ACP, WRITE_ACP et Full control, selon la politique. Edit corrige une instruction et Remove la retire de la préparation. Un bucket dont les ACL sont désactivées par Object Ownership ne reçoit pas ces changements. Les restrictions de type de bucket, portée versionnée, forme d’écriture et lecture complète peuvent désactiver certains modes.

Tags#

Keep unchanged conserve les tags. Modify keys propose Add, Edit et Remove pour préparer les instructions. Dans Add tag instruction, saisissez Key, choisissez Action, puis Value si nécessaire :

• Add if absent ajoute seulement une clé absente.
• Add / update crée ou remplace la valeur.
• Remove retire la clé si elle existe.

Replace all tags conserve uniquement la liste préparée ; Delete all tags retire tous les tags sans supprimer les objets ou versions. Ces deux modes demandent confirmation. Les clés doivent être uniques et non vides ; une valeur peut être vide. Le résultat ne dépasse pas 10 tags par objet, avec 128 positions UTF-16 par clé et 256 par valeur. Certains caractères occupent deux positions UTF-16 ; les clés réservées aws: ne sont pas des tags utilisateur. Modify keys conserve les autres tags et nécessite de lire les tags existants.

Les clés et valeurs sont sensibles à la casse. Utilisez des lettres, nombres, espaces ou _ . : / = + - @. Replace all tags exige au moins un tag ; pour une liste vide, choisissez Delete all tags.

Métadonnées#

Cette page est disponible pour les objets courants. Keep unchanged n’effectue aucune modification. Modify keys utilise Add if absent, Add / update et Remove, avec une instruction par clé. Dans le dialogue, choisissez Type, Key et Value, puis validez.

Pour User-defined, saisissez le suffixe de la clé x-amz-meta-. System-defined propose Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Type, Expires et, pour les types de buckets compatibles, x-amz-website-redirect-location. Expires possède un éditeur de date avec le fuseau affiché et une option Empty value ; ce champ décrit une métadonnée HTTP, pas une règle de suppression.

Replace in scope conserve uniquement les champs préparés dans la portée choisie ; Remove in scope retire tous les champs de cette portée. User-defined (x-amz-meta-*) préserve les champs système éditables ; All editable metadata les inclut. Les champs gérés par le service, tels que la taille et l’ETag, ne sont pas supprimés.

Pour Replace in scope et Remove in scope, User-defined (x-amz-meta-*) est la portée initiale. Le remplacement exige au moins un champ ; utilisez Remove in scope pour vider la portée. Ces deux modes demandent confirmation.

Les noms sont comparés sans distinction de casse et doivent être valides pour HTTP. Les valeurs ne peuvent pas contenir de caractères de contrôle interdits. Les limites affichées sont de 2 048 octets pour les métadonnées utilisateur et de 2 048 octets pour les champs système. Avec Modify keys, S3Client valide le résultat pour chaque objet. Si les métadonnées source sont incomplètes, il refuse une modification qui risquerait de perdre des champs à conserver. Il ne réécrit pas les métadonnées dont les valeurs restent identiques.

Classe de stockage#

Les choix viennent de la politique Storage classes applicable au bucket : chaque classe cible doit autoriser Change storage class on the same object et un chemin de copie disponible. Si aucune classe n’est autorisée, Rewrite storage class est désactivé avec l’infobulle Changing the storage class on the same object is not enabled for this account. Les deux préréglages Google désactivent cette option.

Cochez Rewrite storage class, puis choisissez la classe disponible. La case décochée ne demande aucun changement. Une classe déjà présente sur un objet ne demande pas de réécriture pour ce seul changement ; les autres modifications sélectionnées restent applicables. Cette option s’applique aux objets ordinaires courants, pas aux objets dont la clé se termine par /.

Chiffrement#

La page Encryption présente Pending change, initialement No change. Cliquez sur Change encryption… pour ouvrir Change encryption. Apply to: rappelle la portée et New encryption: propose Do not modify, Use service settings, SSE-S3, SSE-KMS, DSSE-KMS ou SSE-C. Les choix incompatibles sont désactivés avec leur explication. Use service settings laisse le service appliquer ses valeurs lors de l’écriture ; ce choix ne signifie pas absence de chiffrement.

Dans KMS settings, renseignez KMS key:, éventuellement via Favorites…. Une référence vide, lorsqu’elle est autorisée, laisse le service choisir sa clé par défaut. Bucket Key: propose Unspecified, choix initial sans option explicite, Disabled et Enabled, selon la compatibilité SSE-KMS. KMS context: propose Unspecified, choix initial, No additional context et Provide JSON context. Le JSON doit être un objet dont toutes les valeurs sont des chaînes, de 8 KiB au maximum en UTF-8. S3 ne renvoie pas le contexte existant.

Unspecified omet le contexte de la requête : une mise à jour en place conserve le contexte existant, tandis qu’une copie utilise aucun contexte supplémentaire. No additional context demande explicitement un contexte supplémentaire vide et impose une copie, comme Provide JSON context. Une mise à jour sans copie exige un bucket général compatible, une source SSE-S3 ou SSE-KMS, une destination SSE-KMS avec ARN complet de clé, HTTPS, Signature Version 4 et aucune protection Object Lock bloquante. Les versions précises permettent uniquement les changements SSE-KMS en place compatibles ; elles ne disposent d’aucun repli par copie ni de contexte KMS supplémentaire.

Pour SSE-C, renseignez Key: dans New SSE-C key, avec Encoding: sur Base64 ou Hexadecimal, ou utilisez Import file… pour un fichier binaire de 32 octets. Cette clé temporaire définit le chiffrement demandé. Source SSE-C key: > Provide key… dans le dialogue principal sert séparément à lire les objets déjà chiffrés. Choisissez Temporary SSE-C key dans SSE-C read key, renseignez la clé, puis validez avec OK. Elle est utilisée pour tous les objets ou versions inspectés sous cet emplacement ; lancez des opérations séparées pour des clés source différentes. No SSE-C key retire la clé source préparée.

Cliquez sur Use settings pour reporter le choix dans Pending change, sans écrire sur S3. Cancel dans Change encryption conserve le précédent choix confirmé. Pour retirer un changement préparé, sélectionnez Do not modify, puis Use settings. Seul Apply dans le dialogue principal lance l’opération ; Cancel y abandonne les changements préparés. Le diagnostic de l’éditeur explique si chaque objet devra être vérifié pour choisir une mise à jour sans copie ou une copie.

Vérifier le résultat#

La prévisualisation vérifie la sélection, sans appliquer les modifications et sans garantir les permissions d’écriture. Si vous demandez un changement de chiffrement, elle indique s’il peut être appliqué sans copie, s’il exige une copie ou s’il est indisponible.

Apply parcourt toute la cible avec les filtres configurés, même si l’aperçu n’affiche qu’une partie des objets. Les objets peuvent changer entre l’aperçu et l’exécution. Dans les détails d’une erreur, vérifiez Key, Phase et les identifiants de version disponibles. Produced version ID identifie la version créée par une copie. Consultez le suivi et l’interruption des opérations ; interrompre le traitement conserve les changements déjà appliqués.

Après Apply, contrôlez les erreurs de chaque objet et les étapes déjà réussies. Une copie peut avoir réussi alors qu’un changement ultérieur de tags ou d’ACL a échoué. Les changements appliqués ne sont pas restaurés automatiquement ; corrigez la cause et préparez une nouvelle opération sur la portée nécessaire.