[doc] [S3] Pydio creates a *new* container suffixed by `+segments`

Pydio Cells
,
1

While I provided an existing S3-compatible container to my instance during the initial configuration, I got surprised to see that a brand new container got seemingly automatically created by Pydio.
Its name is derived from the original one by appending +segments.

There is no information about this at https://pydio.com/en/docs/cells/v2/s3-compatible-storage and I find this quite surprising.
What would happen, for example, if the access token provided did not allow for new container creation (which would be safer configuration)?

2

Reason is the handling of multi-part uploads by Swift S3 middleware: https://docs.openstack.org/swift/latest/middleware.html#bucket-segments

3

So nothing to do with Pydio, right?
That said, how is the SwiftS3 gateway behaving? Good ?

4
  • About +segments: Nothing to do with Pydio indeed
  • About Swift-backed storage, I wasn’t satisfied (at least in 2.0.5) but I can’t neither blame Pydio nor the middleware for that. Basically my guess is that most file operations (upoad/copy/move/…) are implemented using file-system primitives instead of relying on built-in Swift API calls. This causes many negative effects.

But now I want to see if Pydio could be usable by users to browse/download/tag files uploaded (unencrypted) straight into the object-storage using Cyberduck as a Swift-enabled client to bypass performances/stability bottlenecks). This relies on the assumption that the resync operation be reliable and efficient.

About encryption: Swift provides encrypted-at-rest, but it’s not implemented by my provider.