• Fix phpcs error

• Fix linting errors

• Fix regexp again

• Fix regexp

• More code de-duplication
• More code de-duplication
• cols -> columns

• Move some utility functions to utils.js

• Merge branch 'master' into dev/fontawesome-refactor

• Fix test

• Merge branch 'master' into dev/password-retention

• Suggested changes

Merged into the beta-release branch.

Merged into the beta-release branch.

• Fix Bootstrap's regression - unwanted bold border on tables

• Files API schema refactoring

In D3463#41971, @vanmeeuwen wrote:

item_id, key = 'share_<share-link-id1>', value = '{"john@kolab.org":"r"}' -- for a regular file

So, how do you search fast by the key if you don't know item_id (which is the index here)? Should we just add an index on the key column alone?

In D3463#41947, @vanmeeuwen wrote:

In D3463#41941, @machniak wrote:

• If we move file name, size, mimetype to a separate table whenever we want to list/sort/search we have to make join(s) which will make it slow, and I'd say listing/searching by these three attributes is essential. A simplest listing needs to return at least the file size, name and mimetype, this makes this basic query much complicated/slower.

The assumption is that most if not all "lists" of "files" do not contain a column for the attributes such as size, mtime nor mimetype, let alone allow for "sorting by".

• If we move file name, size, mimetype to a separate table whenever we want to list/sort/search we have to make join(s) which will make it slow, and I'd say listing/searching by these three attributes is essential. A simplest listing needs to return at least the file size, name and mimetype, this makes this basic query much complicated/slower.
• If we wanted to re-use the existing SettingsTrait the table name would have to be fs_file_settings, or you insist on "attributes"?
• If we move permissions to settings/attributes then a "search by share id" query will be very slow, as it will be a non-indexed query on a big table. Therefore I'd keep the fs_permissions table as is.
• App\Handlers\Beta\Files is there for a reason, it extends App\Handlers\Beta\Base class, but I guess I can move it to App\Handlers\Files. Note: that we still have Distlists, Resources, SharedFolders under \Beta, so it would not be consistent.
• I understand fs_chunks needs a sequence column, but what's wrong with the incremented id? Ok, I guess with a generated id we can make it more performant, because we don't need to make an INSERT first. I.e. we'd generate chunk-id, save the chunk-file, then insert. Do you want to make the chunk id unique/primary key?
• @mollekopf, the file_id + sequence is not unique enough, there might be more than one deleted record with the same file_id + sequence combination. Especially considering file updates and partial uploads. SO, I see a reason to have an extra id for the chunk filename.

• Make max chunk size depend on SWOOLE_PACKAGE_MAX_LENGTH option

• Store files in chunks (don't concatenate), some refactorings

• Storage error handling

• File upload/download via unauth API location
• File update API
• Files API schema/implementation refactor (slim-down)

Ok, so the current schema does not cover folders and sharing of folders. I have a simple solution for that:

--- a/src/database/migrations/2022_03_02_100000_create_filesystem_tables.php
+++ b/src/database/migrations/2022_03_02_100000_create_filesystem_tables.php
@@ -30,6 +30,7 @@ function (Blueprint $table) {
             function (Blueprint $table) {
                 $table->string('id', 36)->primary();
                 $table->string('library_id', 36);
+                $table->string('parent_id', 36)->nullable()->index(); // parent folder identifier
                 $table->string('name', 512);
                 $table->bigInteger('size')->unsigned()->default(0);
                 $table->string('mimetype');

@mollekopf I just added the sharing feature. What do you think about this now?

• Add missing FilePermission model

• Fix sharing

• The daemonize option does not work
• Min processes must be >0
• Fixed swoole container

• Fix swoole configuration

• Update swoole container with php8/fedora35/swoole 4.8
• Update the nginx containers to fedora 35 while we're at it
• Daemonize octane, .env.local -> .env.local.example
• Explicit octane config

• Add Swoole config section to config/octane.php

• Update spomky-labs/otphp package for better PHP 8.1 support

Close in favour of D3409

• Fix typo in phpdoc