g7 — Object Storage/Limitations

g7 Limitations

These are the current boundaries of what g7 can do.


Upload size

100 MiB per PUT. A single put() call (or PUT through the management proxy) cannot exceed 100 MiB. Larger objects are not supported — there is no multipart upload.


Unsupported features

No multipart upload. Objects must be uploaded in a single request. Chunked or resumable uploads are not available.

No conditional writes. There is no If-None-Match or If-Match semantics on put(). Last write wins.

No object versioning. Overwriting an existing key replaces it permanently. There is no version history or soft-delete.

No list delimiter. list() does not support a delimiter parameter for simulating a directory hierarchy. Use prefix filtering and parse paths in application code.

No custom metadata. Objects support httpMetadata (content type, cache control) but not arbitrary key-value metadata beyond that.

No server-side copy. There is no copy or move operation. To copy an object, read it and write it under the new key.


Access

Buckets are not publicly accessible by default. All access goes through a Cell binding. There are no pre-signed URLs or public bucket policies.

No direct access outside a Cell. You cannot read or write g7 objects directly from client-side code or external services. Cells are the access layer.


See also