Modify child objects

Child object modification recursively applies the same instructions to objects in a bucket or logical folder. The selected folder itself is not a child object. All keys ending in / and their versions are ignored, even when they contain data, regardless of the instructions or inclusion rules. Objects under those prefixes are still processed normally. You can combine several types of changes.

Choose a scope and prepare access#

In the S3 pane, select a single bucket or current logical folder. Without Show versions, the menu offers Modify child objects… for current objects. With Show versions, it offers Modify child object versions…, which processes current and noncurrent versions and ignores delete markers.

Version mode requires Object versions, listing permissions and at least one change applicable to versions: ACLs, tags or in-place encryption updates. When the bucket supports reading its versioning state with Read bucket versioning, that state must be confirmed enabled or suspended. Without that read, an unknown local state does not prevent processing; a bucket known never to have had versioning enabled remains excluded. On Amazon S3, listing requires s3:ListBucketVersions, and reading the state, when used, requires s3:GetBucketVersioning.

Browser display filters do not restrict this command. Instructions apply throughout the scope under Location, subject to the dialog’s filters. Historical folders and delete markers cannot serve as roots.

Open File > Accounts…, select the account, click Edit…, then open Capabilities. Check these settings: ACL policy, Object tags, Storage classes, Encryption and Encryption policies must match service support, the bucket type and current-object or version processing. Enabling these settings grants no permissions.

Reads and changes require permissions appropriate to the instructions: listing, property or content reads for rewrites, ACL or tag reads and writes, object writes and KMS key access. Preserving Object Lock during a rewrite may require retention and legal hold read permissions and permissions to preserve that protection.

To change encryption without copying, check Capabilities > Encryption > Update object encryption without copying, the update permissions and the KMS permissions described in encryption.

Understand the effects before applying#

Rewrites follow the destination account’s S3 copy conditions. Disabling a source condition permits copying without that check: the preliminary HEAD does not guarantee that a mutable source remains unchanged during its rewrite. Identity checks before writing remain active.

Changing metadata or storage class rewrites current objects by copying them. With versioning enabled, this creates new current versions and increases retained storage. Archived objects must be accessible for copying; restoration may be required.

A compatible encryption change can run in place without copying data. Otherwise, current objects may require a copy. Processing exact versions uses only the supported in-place change; it does not offer metadata or storage class changes. Combining encryption and ACL changes is rejected in version mode: run them as separate operations. For current objects, that combination requires a copy and may create a new version, even when encryption alone could be updated in place.

ACLs and tags do not require replacing object data. Combined with a rewrite, they are applied to the object produced by that rewrite. A filtered ACL read may hide some grants; the interface asks for your agreement if the change could remove them. The service’s ownership rules determine the owner of a rewritten object.

Partial success is not undone if another instruction fails. Avoid changing the same objects in another client during processing.

Prepare instructions#

1. Open the context command for the intended mode.
2. Check Location and Apply to.
3. Configure the relevant pages below; availability depends on capabilities and mode.
4. Select Filters in the left-hand menu to define filters.
5. Select Preview, then click Run preview below the results list to inspect the selection.
6. Click Apply, then accept confirmations for the actual scope.
7. Monitor the operation and its errors. Reopen the properties of representative objects when it finishes.

At least one valid change is required. Pages marked (!) contain values that need correction. If account settings change, close and reopen the dialog.

ACLs#

Keep unchanged, selected initially, requests no ACL change.

If another instruction rewrites the content, Keep unchanged requests ACL preservation when the account’s ACL operations are enabled; that preservation must be achievable. If Enable ACL operations for this account is unchecked, ACL modification modes are unavailable and the rewrite uses the destination default without ACL requests or headers. Keep unchanged then does not guarantee preservation of the existing ACL, even within the same bucket. Metadata, storage class and encryption changes remain possible under their own requirements. See the effects of local deactivation.

For a grantee, Add permissions adds grants, Set permissions replaces its grants, Remove permissions removes the selected permissions and Remove grantee removes it entirely. Choose grantee… selects a known grantee. Canonical user requires a canonical ID; S3 group requires an allowed group; Email (removal only) only removes an older email grantee.

Only one instruction is allowed per grantee identity, with a maximum of 1,000 instructions. A new instruction initially selects Add permissions, Canonical user and READ. Save this grantee in the account saves the entry when you accept the instruction, or when you accept the picker in Replace all grants; canceling the main dialog afterward does not remove that entry. See ACL grantees and permissions.

Object permissions include READ, READ_ACP, WRITE_ACP and Full control, according to the policy. Edit changes an instruction and Remove removes it from the draft. Buckets whose ACLs are disabled by Object Ownership cannot receive these changes. Bucket type, version scope, write form and complete-read restrictions can disable particular modes.

Tags#

Keep unchanged preserves tags. Modify keys provides Add, Edit and Remove to prepare instructions. In Add tag instruction, enter Key, choose Action and enter Value when required:

• Add if absent adds only a missing key.
• Add / update creates or replaces the value.
• Remove removes the key if present.

Replace all tags retains only the prepared set; Delete all tags removes tags without deleting objects or versions. Both require confirmation. Keys must be unique and nonempty; values may be empty. The result must not exceed 10 tags per object, with 128 UTF-16 character positions per key and 256 per value. Some characters use two UTF-16 positions; reserved aws: keys are not user tags. Modify keys preserves other tags and requires reading the existing tags.

Keys and values are case-sensitive. Use letters, numbers, spaces or _ . : / = + - @. Replace all tags requires at least one tag; use Delete all tags for an empty set.

Metadata#

This page is available for current objects. Keep unchanged makes no changes. Modify keys uses Add if absent, Add / update and Remove, with one instruction per key. In the dialog, choose Type, Key and Value, then accept it.

For User-defined, enter the key suffix after x-amz-meta-. System-defined offers Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Type, Expires and, for supported bucket types, x-amz-website-redirect-location. Expires has a date editor with the displayed time zone and an Empty value option; this is HTTP metadata rather than a deletion rule.

Replace in scope retains only prepared fields within the selected scope; Remove in scope removes every field in that scope. User-defined (x-amz-meta-*) preserves editable system fields; All editable metadata includes them. Service-managed fields such as size and ETag are not removed.

For Replace in scope and Remove in scope, User-defined (x-amz-meta-*) is the initial scope. Replacement requires at least one field; use Remove in scope to clear the scope. Both modes require confirmation.

Names are compared case-insensitively and must be valid HTTP names. Values cannot contain prohibited control characters. The displayed limits are 2,048 bytes for user metadata and 2,048 bytes for system fields. With Modify keys, S3Client validates the result for each object. If source metadata is incomplete, it rejects a change that could lose fields that need to be kept. It does not rewrite metadata whose values remain unchanged.

Storage class#

Choices come from the bucket’s Storage classes policy: each destination class must allow Change storage class on the same object and an available copy path. If no class is allowed, Rewrite storage class is disabled with the tooltip Changing the storage class on the same object is not enabled for this account. Both Google presets disable this option.

Select Rewrite storage class, then choose an available class. Leaving the checkbox clear requests no change. An object already using the requested class needs no rewrite for that change alone; other selected changes still apply. This option applies to ordinary current objects, rather than objects with keys ending in /.

Encryption#

The Encryption page shows Pending change, initially No change. Click Change encryption… to open Change encryption. Apply to: identifies the scope, while New encryption: offers Do not modify, Use service settings, SSE-S3, SSE-KMS, DSSE-KMS or SSE-C. Incompatible choices are disabled with an explanation. Use service settings lets the service apply its defaults during the write; it does not mean unencrypted data.

Under KMS settings, enter KMS key:, optionally using Favorites…. An empty reference, where allowed, lets the service choose its default key. Bucket Key: offers Unspecified, the initial choice with no explicit setting, Disabled and Enabled, depending on SSE-KMS compatibility. KMS context: offers Unspecified, selected initially, No additional context and Provide JSON context. JSON must be an object containing only string values, no larger than 8 KiB in UTF-8. S3 does not return the existing context.

Unspecified omits the context from the request: an in-place update preserves the existing context, while a copy uses no additional context. No additional context explicitly requests an empty additional context and requires a copy, as does Provide JSON context. An update without copying requires a compatible general purpose bucket, an SSE-S3 or SSE-KMS source, an SSE-KMS destination with a full key ARN, HTTPS, Signature Version 4 and no blocking Object Lock protection. Exact versions support only compatible in-place SSE-KMS changes; they have no copy fallback and cannot receive additional KMS context.

For SSE-C, enter Key: under New SSE-C key, with Encoding: set to Base64 or Hexadecimal, or use Import file… for a 32-byte binary file. This temporary key defines the requested encryption. Separately, Source SSE-C key: > Provide key… in the main dialog supplies access to existing encrypted objects. Choose Temporary SSE-C key in SSE-C read key, enter the key and confirm with OK. It is used for every object or version inspected under that location; use separate operations for different source keys. No SSE-C key clears the pending source key.

Click Use settings to return the choice to Pending change, without writing to S3. Cancel in Change encryption keeps the previously confirmed choice. To clear a pending change, select Do not modify, then Use settings. Only Apply in the main dialog starts the operation; Cancel there discards pending changes. The editor’s diagnostic explains when each object must be checked to choose between an update without copying and a copy.

Check results#

The preview checks the selection without applying changes or guaranteeing write permissions. If you request an encryption change, it indicates whether the change can be applied without copying, requires a copy or is unavailable.

Apply scans the entire target using the configured filters, even if the preview shows only some objects. Objects may change between preview and execution. In error details, check Key, Phase and the available version IDs. Produced version ID identifies the version created by a copy. See monitoring and interrupting operations; interrupting processing keeps changes already applied.

After Apply, inspect per-object errors and completed steps. A copy may succeed while a later tag or ACL change fails. Applied changes are not automatically restored; fix the cause and prepare another operation for the necessary scope.