Keep the original file/directory structure on disk (ocis/s3ng)

[MrPixel1]

Describe the bug

I could not find documentation on how to keep the original file/directory structure on disk.
There are various reasons for this use case, e.g. having other services directly interacting with the files (using webdav may or may not be an applicable workaround) or not wanting a vendor lock-in.

Expected behavior

Documentation, e.g. here, on how to configure how files and directories are persisted on the disk/in the S3 buckets.

Actual behavior

There's no documentation to my knowledge.

Setup

docker-compose with the following environment variables:

- "STORAGE_SYSTEM_DRIVER=ocis"
- "STORAGE_USERS_DRIVER=s3ng"
- "STORAGE_USERS_S3NG_ENDPOINT=http://storage:3900"
- "STORAGE_USERS_S3NG_REGION=region"
- "STORAGE_USERS_S3NG_ACCESS_KEY=key"
- "STORAGE_USERS_S3NG_SECRET_KEY=key"
- "STORAGE_USERS_S3NG_BUCKET=bucket"

The issue applies to both the s3ng and ocis storage drivers.

[micbar]

@MrPixel1 I am not sure if i get the question right.

I assume you would like to write to the ocis filesystem bypassing the ocis APIs.

This is not possible with the two currently supported drivers (DecomposedFS, S3NG). Both drivers need exclusive access to the filesystem because it deconstructs the file tree and optimizes the reverse lookup.

There is the EOS driver available which is really built around that use case where aplications can directly access the filesystem.

There are plans to build a new SMB driver for samba file systems which would also support that use case.

[MrPixel1]

Thanks for the info! That's correct: I would like to be able to access the files bypassing ocis, but I understand this isn't possible (I thought I read that it's possible, hence my assumption).
Let me know if it makes sense opening a more detailed feature request.

I'll inform myself about the EOS driver, I wasn't aware of it.