FailedCount int64 `json:"failedReplicationCount"`
	// Total number of failed operations
	ReplicatedCount int64 `json:"replicationCount"`
	// Last bucket/object replicated.
	Bucket string `json:"bucket,omitempty"`
	Object string `json:"object,omitempty"`
}

// VersionPurgeStatusType represents status of a versioned delete or permanent delete w.r.t bucket replication

sleep 10

./mc stat --no-list sitea/bucket/new-test-encrypted-object
./mc stat --no-list siteb/bucket/new-test-encrypted-object
./mc stat --no-list sitec/bucket/new-test-encrypted-object

./mc ls -r sitea/bucket/
./mc ls -r siteb/bucket/
./mc ls -r sitec/bucket/

			}
		case "sz":
			z.Size, err = dc.ReadInt64()
			if err != nil {
				err = msgp.WrapError(err, "Size")
				return
			}
		case "os":
			z.Objects, err = dc.ReadUint64()
			if err != nil {
				err = msgp.WrapError(err, "Objects")
				return
			}
		case "vs":
			z.Versions, err = dc.ReadUint64()
			if err != nil {
				err = msgp.WrapError(err, "Versions")
				return
			}

        V1 extends @Nullable Object,
        V2 extends @Nullable Object,
        V3 extends @Nullable Object,
        V4 extends @Nullable Object,
        V5 extends @Nullable Object,
        U extends @Nullable Object> {
      /**
       * Applies this function to five inputs, or throws an exception if unable to do so.
       *

#### Secret Keys

The MinIO server uses a unique, randomly generated secret key per object also known as, Object Encryption Key ([OEK](#oek)). Neither the client-provided SSE-C key nor the KMS-managed key is directly used to en/decrypt an object. Instead, the OEK is stored as part of the object metadata next to the object in an encrypted form. To en/decrypt the OEK another secret key is needed also known as, Key Encryption Key ([KEK](#kek)).

### List of Amazon S3 Object APIs not supported on MinIO

- ObjectACL (Use [bucket policies](https://docs.min.io/community/minio-object-store/administration/identity-access-management/policy-based-access-control.html) instead)

## Object name restrictions on MinIO

    /**
     * Retrieves all Kerberos keys from the authenticated subject.
     *
     * @return array of KerberosKey objects
     */
    public KerberosKey[] getKeys() {
        List<Key> serverKeys = new ArrayList<>();

        Set<Object> serverPrivateCredentials = this.subject.getPrivateCredentials();
        for (Object credential : serverPrivateCredentials) {
            if (credential instanceof KerberosKey) {

			metaErr = metadata(object.Name, policy.GetObjectAction)
			lastObjMetaName = object.Name
		}
		content := ObjectVersion{}
		content.Key = s3EncodeName(object.Name, encodingType)
		content.LastModified = amztime.ISO8601Format(object.ModTime.UTC())
		if object.ETag != "" {
			content.ETag = "\"" + object.ETag + "\""
		}
		content.Size = object.Size

import java.util.Iterator;
import java.util.Map.Entry;
import java.util.Objects;
import org.jspecify.annotations.Nullable;

/**
 * Implementation for {@link FilteredMultimap#values()}.
 *
 * @author Louis Wasserman
 */
@GwtCompatible
final class FilteredMultimapValues<K extends @Nullable Object, V extends @Nullable Object>
    extends AbstractCollection<V> {
  @Weak private final FilteredMultimap<K, V> multimap;

failure whereas in MinIO erasure code you can lose as many as half of drives and still the data remains safe. Further, MinIO's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As MinIO encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime of the server. MinIO's erasure coded backend...