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

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)?

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

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

  • 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.