gproxy-file
English | 简体中文
Optional file-content storage for GPROXY, using Apache OpenDAL's local filesystem
and S3-compatible services. Cloudflare R2 uses the S3 backend. The common API is
OpenDAL's Operator, re-exported by this crate.
Application ownership, file metadata records, retention, and upstream resource-ID mappings stay with the caller. This crate does not depend on SeaORM or gproxy core.
Features
Neither fs nor s3 is enabled by default.
| Feature | Backend | Native | Workers WASM |
|---|---|---|---|
fs |
Local filesystem | Yes | No |
s3 |
S3-compatible object storage, including R2 | Yes | Yes |
An embedding crate can make the entire dependency optional:
[]
= { = "4.0.0", = true, = false, = ["fs", "s3"] }
Local files
Enable fs. File operations run inside a Tokio runtime on native targets.
let files = filesystem?;
files.write.await?;
let content = files.read.await?.to_bytes;
let metadata = files.stat.await?;
files.delete.await?;
Fs and FsConfig are also re-exported for configuring OpenDAL directly.
S3 and Cloudflare R2
Enable s3. Pass the bucket, endpoint, region, and credentials to the standard
OpenDAL builder. For R2, the region is auto:
use ;
let files = s3?;
files.write.await?;
For AWS S3, use the bucket's AWS region and the appropriate endpoint. Authentication, request signing, object paths, multipart operations, and errors follow OpenDAL. The default HTTP transport uses reqwest with rustls on native targets and the host Fetch API on WASM. Concurrent multipart tasks use Tokio on native targets and the WASM microtask executor on Workers.
Hosts can inject their own OpenDAL HTTP transport:
use ;
let files = s3_with_transport?;
Streaming and other operations
Use the normal OpenDAL Operator API for readers, writers, ranges, listing,
metadata, and deletion. Backend capabilities remain those of OpenDAL.
let mut writer = files.writer.await?;
writer.write.await?;
writer.write.await?;
writer.close.await?;
let part = files.read_with.range.await?;
Advanced OpenDAL types are available through gproxy_file::opendal.
Validation
Tests exercise actual temporary local files, streaming writes and range reads, plus S3 signing, encoded paths, reads, writes, metadata, and deletion through an injected test transport. WASM compilation is checked separately; these tests do not contact a live S3/R2 account.