bash
evidence and going to ask publicly on MinIO's Github.
The issue isn't complex at all. Basically you have trash on Windows/Linux/macOS whatever. If you delete files from your computer, they land in Trash. We can say they're versioned as their latest version is available for restore.
From a UI point of view, after deletion, you wouldn't expect for these deleted entries to appear in a location from where they were originally deleted. They're now in Trash (available for further deletion or restore) and shouldn't be present anywhere else.
MinIO shows the folder hierarchy in the original location despite that it was all deleted and it's correct place is Trash. I don't think it's a correct behavior from purely "files&directories" UI point of view. (edited)PUT folder/
PUT folder/file.txt
then: LIST folder
might not return you the folder/file.txt
Apparently they mention it in here: https://min.io/docs/minio/container/operations/checklists/thresholds.html#id6
I am not sure, but we may have to change the way we create folders to overcome this issue. E.g. instead of folder/
we would rather create folder/.empty
to not cause conflicting keys.alist
has its own Web front-end, so you can self-host it yourself and then expose back-end to other users: https://al.nn.ci/
With Rclone that's not possible yet, you can use: https://rclone.org/commands/rclone_serve/ however there is no documentation how to "host" serve command permanently e.g. on your self-hosted server.
One more difference is selection of supported back-ends. Alist seem to target Chinese providers which Rclone doesn't support at the moment.flutter --version
and flutter doctor
? (edited)kapsa
ecosystem, which at this stage is only some naming convetion we use internally.
The way that our Debian build works, by default picked up kapsa
as a binary name.
We may actually resolve it to S3Drive
or s3drive
, so it doesn't scare people off.
In the future we may include all of our future products as part of the Kapsa suite, but that's more of marketing gimmick than a technical challenge.
I hope that sheds some light on these shenanigans. (edited)kapsa
ecosystem, which at this stage is only some naming convetion we use internally.
The way that our Debian build works, by default picked up kapsa
as a binary name.
We may actually resolve it to S3Drive
or s3drive
, so it doesn't scare people off.
In the future we may include all of our future products as part of the Kapsa suite, but that's more of marketing gimmick than a technical challenge.
I hope that sheds some light on these shenanigans. (edited)mount
at the moment, we hope to have it implemented in the future.
Speed of file operations for uploads/downloads to Rclone back-ends is visible in the Transfers tab, but only if operation was initiated from the S3Drive (not the mount).
rclone mount
command. We're using standard VFS cache settings: https://rclone.org/commands/rclone_mount/#vfs-file-caching with --vfs-cache-max-size
parameter being set to 1024M (not yet configurable from the app) and the --vfs-cache-mode
set to Full (configurable in the Profile settings).
Cache path is default as well, I can look it up what it is. What's your OS?
I've made a note to provide both cache path and size configurable from the app.
flutter --version
and flutter doctor
? (edited)