tencent cloud

Cloud Object Storage

Release Notes and Announcements
Release Notes
Announcements
Product Introduction
Overview
Features
Use Cases
Strengths
Concepts
Regions and Access Endpoints
Specifications and Limits
Service Regions and Service Providers
Billing
Billing Overview
Billing Method
Billable Items
Free Tier
Billing Examples
Viewing and Downloading Bill
Payment Overdue
FAQs
Getting Started
Console
Getting Started with COSBrowser
User Guide
Creating Request
Bucket
Object
Data Management
Batch Operation
Global Acceleration
Monitoring and Alarms
Operations Center
Data Processing
Content Moderation
Smart Toolbox
Data Processing Workflow
Application Integration
User Tools
Tool Overview
Installation and Configuration of Environment
COSBrowser
COSCLI (Beta)
COSCMD
COS Migration
FTP Server
Hadoop
COSDistCp
HDFS TO COS
GooseFS-Lite
Online Tools
Diagnostic Tool
Use Cases
Overview
Access Control and Permission Management
Performance Optimization
Accessing COS with AWS S3 SDK
Data Disaster Recovery and Backup
Domain Name Management Practice
Image Processing
Audio/Video Practices
Workflow
Direct Data Upload
Content Moderation
Data Security
Data Verification
Big Data Practice
COS Cost Optimization Solutions
Using COS in the Third-party Applications
Migration Guide
Migrating Local Data to COS
Migrating Data from Third-Party Cloud Storage Service to COS
Migrating Data from URL to COS
Migrating Data Within COS
Migrating Data Between HDFS and COS
Data Lake Storage
Cloud Native Datalake Storage
Metadata Accelerator
GooseFS
Data Processing
Data Processing Overview
Image Processing
Media Processing
Content Moderation
File Processing Service
File Preview
Troubleshooting
Obtaining RequestId
Slow Upload over Public Network
403 Error for COS Access
Resource Access Error
POST Object Common Exceptions
API Documentation
Introduction
Common Request Headers
Common Response Headers
Error Codes
Request Signature
Action List
Service APIs
Bucket APIs
Object APIs
Batch Operation APIs
Data Processing APIs
Job and Workflow
Content Moderation APIs
Cloud Antivirus API
SDK Documentation
SDK Overview
Preparations
Android SDK
C SDK
C++ SDK
.NET(C#) SDK
Flutter SDK
Go SDK
iOS SDK
Java SDK
JavaScript SDK
Node.js SDK
PHP SDK
Python SDK
React Native SDK
Mini Program SDK
Error Codes
Harmony SDK
Endpoint SDK Quality Optimization
Security and Compliance
Data Disaster Recovery
Data Security
Cloud Access Management
FAQs
Popular Questions
General
Billing
Domain Name Compliance Issues
Bucket Configuration
Domain Names and CDN
Object Operations
Logging and Monitoring
Permission Management
Data Processing
Data Security
Pre-signed URL Issues
SDKs
Tools
APIs
Agreements
Service Level Agreement
Privacy Policy
Data Processing And Security Agreement
Contact Us
Glossary
DocumentationCloud Object Storage

Object Lock Overview

Focus Mode
Font Size
Last updated: 2024-03-25 15:33:39

Overview

Tencent Cloud Object Storage (COS) offers the object lock function, enabling users to set a retention period during which objects cannot be modified or deleted.
The object lock function is currently implemented at the object level, allowing users to set a retention period for one or multiple objects. Users can also enable the object lock configuration for a bucket, thereby setting a default object lock for objects newly uploaded to the bucket.
Note:
Once an object is set with object lock, it does not support the removal of the object lock, nor does it support the reduction of the retention period. It only permits the extension of the retention period.
Note:
Based on the object lock function, COS can meet stringent electronic record retention requirements, including compliance with SEC Rule 17a-4(f), FINRA 4511, CFTC 1.31, and other regulatory standards.
SEC 17A-4 is a regulation promulgated by the U.S. Securities and Exchange Commission pursuant to the U.S. Securities Exchange Act of 1934. This regulation outlines data retention, indexing, and accessibility requirements applicable to companies engaged in financial securities trading or brokerage businesses, such as stocks, bonds, and futures. According to this regulation, many types of transaction records must be retained and cannot be overwritten or erased, with a period of immediate access within two years and non-immediate access for at least six years.

Enabling the Object Lock Function for a Bucket

Before locking an object, you need to enable the write once read many (WORM) function in the bucket. Note that enabling the object lock function merely marks the bucket as the status of "capable of using the object lock function", it does not automatically lock all objects in the bucket. Once the WORM function is enabled for the bucket, users can choose to enable the object lock function for specific objects, or maintain an unlocked state.
Once the object lock configuration for a bucket is enabled, it cannot be disabled. Buckets with the object lock configuration enabled will be subject to the following restrictions:
Enabling version control is not supported. If version control is already enabled for the bucket, the object lock configuration cannot be enabled.
Enabling bucket replication is not supported. This is because bucket replication requires version control to be enabled.
Enabling intelligent tiering configuration is not supported. If intelligent tiering configuration is already enabled for the bucket, the object lock configuration cannot be enabled.
The use of append upload is not supported.

How to Use

You can enable the object lock configuration for your bucket via APIs.

Using REST APIs

Invoke the PUT Bucket ObjectLockConfiguration interface to enable the object lock configuration.

Setting a Retention Period for an Object

Retention Period

Once the object lock function is enabled for a bucket, users can configure a lock retention period for the objects in the bucket. COS stores a timestamp in the object's metadata to denote the expiration of the lock (RetainUntilDate). Before the retention period:
The object cannot be deleted or modified.
The storage type of the object cannot be modified.
The HTTP headers and user metadata of the object cannot be modified, including Content-Type, Content-Encoding, Content-Language, Content-Disposition, Cache-Control, Expires, and x-cos-meta-.
Users can set the retention period for a specified object. During the object uploading process, the retention period can be configured through the x-cos-object-lock-retain-until-date header; after the object is uploaded, the retention period can be set via the PUT Object Retention interface.
Users can also set the default configuration for the bucket to automatically configure the retention period during the object uploading process. For more details, refer to the default configuration of the bucket.

How to Use

You can set a retention period for an object through APIs.

Using REST APIs

Set a retention period for an object during the uploading process.
Invoke the uploading interfaces (PutObject, InitiateMultipartUploads, and PostObject), and simultaneously pass in the object lock-related headers or form fields. For more details, refer to the following API documentation:
Set a retention period for the object after it is uploaded. For more details, refer to PUT Object Retention.
View the retention period of the object. For more details, refer to GET Object Retention.

Setting a Default Retention Period for a Bucket

COS supports adding a default object lock retention period for a bucket. The period is measured in days. When a user uploads an object without carrying an object lock header, the object will automatically be locked according to the retention period configured in the bucket. However, when a user uploads an object carrying an object lock header, the bucket configuration will be ignored, and the retention period will be set according to the header.
Note:
The default retention period for a bucket can be shortened, extended, or disabled.
Configuring the default retention period for a bucket will only affect subsequently added objects and will not impact the lock status of existing objects.
The following examples illustrate the impact of the default bucket configuration on the retention period of objects.
Object Upload Time

Default Bucket Configuration

Header During the Object Uploading Process

Object Lock Expiration Time

2023-01-01T18:30:00Z
7 days

x-cos-object-lock-retain-until-date: 2023-01-02T18:30:00Z
2023-01-02T18:30:00Z
2023-01-01T18:30:00Z
7 days
x-cos-object-lock-retain-until-date: 2023-01-20T18:30:00Z
2023-01-20T18:30:00Z
2023-01-01T18:30:00Z
7 days
Without carrying

2023-01-08T18:30:00Z
2023-01-01T18:30:00Z
Unconfigured

x-cos-object-lock-retain-until-date: 2023-01-02T18:30:00Z
2023-01-02T18:30:00Z
2023-01-01T18:30:00Z
Unconfigured
x-cos-object-lock-retain-until-date: 2023-01-20T18:30:00Z
2023-01-20T18:30:00Z
2023-01-01T18:30:00Z
Unconfigured
Without carrying
Unlocked

How to Use

You can set the default configuration of object lock for a bucket through APIs.

REST APIs

You can manage the object lock directly through the following APIs:

Limitations

1. The object lock function is currently only available to customers in the allowlist. For details, contact us.
2. The object lock function does not support the version control function. Buckets with the object lock function enabled do not support the enabling of version control, and buckets with version control in an enabled or paused state do not support the enabling of the object lock function.
3. The object lock function does not support the bucket replication function. As the object lock function is not compatible with the version control function, and the source and target buckets must have version control enabled under the bucket replication rules, buckets with the object lock function enabled cannot be used as the source or target buckets for bucket replication.
4. The object lock function does not support the intelligent tiering function. Buckets with the object lock function enabled do not support the enabling of intelligent tiering configuration, and once the intelligent tiering configuration is enabled in a bucket, it does not support the enabling of the object lock function.
5. The relationship between the object lock function and lifecycle rules is as follows. When an object is within its retention period, the sedimentation and deletion operations configured in the lifecycle do not take effect; once the retention period of an object expires, the sedimentation and deletion operations configured in the lifecycle can function normally.
Lifecycle Rule
Object Lock Retention Period
Lifecycle Execution Performance
Object sedimentation after 20 days

30-day retention period

On the 20th day after the upload, the object does not undergo sedimentation. On the 31st day after the upload, the object undergoes sedimentation.
Object deletion after 20 days

30-day retention period
On the 20th day after the upload, the object is not deleted. It is deleted on the 31st day after the upload.
Object sedimentation after 20 days
10-day retention period
The object undergoes sedimentation normally 20 days after the upload.
Object deletion after 20 days
10-day retention period
The object is deleted normally 20 days after the upload.
6. After the object lock function is enabled for a bucket, file fragments are not subject to object lock rules, allowing users to clear file fragments in the bucket.
7. Once the object lock function is enabled, it cannot be disabled.
8. After the object lock function is enabled, the bucket and object ACL can be modified.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback