> For the complete documentation index, see [llms.txt](https://docs.zus.network/zus-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zus.network/zus-docs/system-overview/storage/file-operations.md).

# File Operations

The **File Operations** section of Züs provides an in-depth look at how users can interact with their decentralized storage. Züs supports a variety of file management capabilities, ensuring **secure, efficient, and fault-tolerant data operations** within the ecosystem.

File operations on Züs include **uploading, downloading, sharing, recovery, replication, and encryption**, all of which are designed to work seamlessly within the decentralized storage architecture.

### **Key Features of File Operations**

Züs provides several core file operation functionalities:

#### **Upload and Download**

Züs allows users to **securely upload and retrieve files** from blobbers. The system ensures high availability by leveraging erasure coding and redundancy mechanisms. Read and write operations are optimized for performance and data integrity.

#### **File Sharing**

Users can share files either **publicly or privately**. Private sharing uses **Proxy Re-Encryption**, ensuring secure access without compromising encryption keys. AuthTickets are used for authentication and access control, making file sharing seamless and secure.

#### **Partial Error Recovery**

In the event of **failed operations** due to network inconsistencies, Züs provides **repair and rollback mechanisms**. These ensure that blobbers remain synchronized and that users do not experience data loss due to temporary failures.

#### **Streaming**

Züs supports **video and media streaming**, using efficient chunk-based downloads and adaptive playback mechanisms. The system dynamically optimizes storage and retrieval to ensure smooth media access.

#### **Recovery and Replication**

To maintain data integrity, Züs provides **self-healing mechanisms** where missing shards are automatically reconstructed and redistributed. Replication features allow for seamless data migration between servers.

#### **S3FS Setup and Usage**

Users can integrate Züs with **S3-compatible tools**, enabling cloud-based applications to interact with the storage network just like they would with traditional S3 cloud storage services.

#### **Encryption and Compression**

Züs implements **end-to-end encryption (E2EE)**, allowing users to encrypt files before upload, ensuring that even storage providers (blobbers) cannot access raw data. Compression features optimize storage efficiency.

Got it 👍\
This piece is more of a **clarification / troubleshooting note** than part of the core setup.

📍 **Best place to add it**:

* Either at the **end of the documentation** in a new section called **“Known Issues & Troubleshooting”**,
* OR directly **under the "Directory Listings" / "List" command section**, since that’s where users might run into this error.

Here’s a rewritten version in clean, GitBook-ready Markdown:

#### Note on List Errors (Warp Tool)

All Züs repos (`zboxcli`, `rclone_zus`, `zs3server`, `gosdk`, and `eblobber`) handle **list operations** correctly.

The list errors reported during testing were not due to rclone\_zus itself, but to the **`./warp` benchmarking tool**. The issue comes from differences in the default `pagelimit` values:

* **rclone\_zus** → `pagelimit = 1000`
* **zboxcli** → `pagelimit = 500`
* **zs3server (S3 list API)** → `pagelimit = 500`
* **warp tool** → `pagelimit = 100` (default)

When running `./warp` with a large number of objects (e.g., 5,000 or 10,000), errors may appear because the tool is only fetching 100 keys per request.

Use the `--max-keys` flag in `./warp` to increase the limit (e.g., `--max-keys 1000`) so it aligns with rclone\_zus and other Züs components.