NoLock     bool             // does not lock the delete bucket call if set to 'true'
	NoRecreate bool             // do not recreate bucket on delete failures
	Force      bool             // Force deletion
	SRDeleteOp SRBucketDeleteOp // only when site replication is enabled
}

// BucketOptions provides options for ListBuckets and GetBucketInfo call.
type BucketOptions struct {
	Deleted    bool // true only when site replication is enabled

    private static final Logger log = LoggerFactory.getLogger(SID.class);

    static final String[] SID_TYPE_NAMES =
            { "0", "User", "Domain group", "Domain", "Local group", "Builtin group", "Deleted", "Invalid", "Unknown" };

    /**
     * Flag indicating that SIDs should be resolved to names.
     */
    public static final int SID_FLAG_RESOLVE_SIDS = 0x0001;

    /**
     * Well known SID: EVERYONE

### CVE-2025-5187: Nodes can delete themselves by adding an OwnerReference

                    .execute(ActionListener.wrap(res -> {
                        logger.info("Deleted .crawler indices.");
                        coordinator.completeOperation("clear_crawler_index");
                    }, e -> {
                        logger.warn("Failed to delete .crawler.* indices.", e);
                        coordinator.completeOperation("clear_crawler_index");
                    }));

// things like the available devices, resource manager etc.
// TFE_Context must outlive all tensor handles created using it. In other
// words, TFE_DeleteContext() must be called after all tensor handles have
// been deleted (with TFE_DeleteTensorHandle).
//
// TODO(ashankar): Merge with TF_Session?
typedef struct TFE_Context TFE_Context;

TF_CAPI_EXPORT extern TFE_Context* TFE_NewContext(

	}
	set := s.getHashedSet(object)
	return set.DeleteObject(ctx, bucket, object, opts)
}

// DeleteObjects - bulk delete of objects
// Bulk delete is only possible within one set. For that purpose
// objects are group by set first, and then bulk delete is invoked
// for each set, the error response of each delete will be returned

- Fixes an issue that can result in namespaced custom resources being orphaned when their namespace is deleted, if the CRD defining the custom resource is removed concurrently with namespaces being deleted, then recreated. ([#93790](https://github.com/kubernetes/kubernetes/pull/93790), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Apps]

    /**
     * This method will delete the file or directory specified by this
     * <code>SmbResource</code>. If the target is a directory, the contents of
     * the directory will be deleted as well. If a file within the directory or
     * it's sub-directories is marked read-only, the read-only status will
     * be removed and the file will be deleted.
     *

        src[srcIndex + 16] = 0x00; // hex code
        src[srcIndex + 17] = (byte) 0xFE; // All flags except one: 11111110
        // Bit 7: group (1)
        // Bits 6-5: owner node type (11 = 3)
        // Bit 4: being deleted (1)
        // Bit 3: in conflict (1)
        // Bit 2: active (1)
        // Bit 1: permanent (1)

        // MAC address
        byte[] testMac = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

If you use ThirdPartyResource objects, they have moved from being namespaced-scoped to be cluster-scoped. Before upgrading to 1.3.0, export and delete any existing ThirdPartyResource objects using a 1.2.x client:

kubectl get thirdpartyresource --all-namespaces -o yaml > tprs.yaml
kubectl delete -f tprs.yaml

After upgrading to 1.3.0, re-register the third party resource objects at the root scope (using a 1.3 server and client):