* fixes#22819
The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.
This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.
Whenever a file was deleted (also from trash), the tag mapping is
pointing at a fileid that doesn't exist any more.
This cleanup job will delete such orphaned mapping entries.
* Register OCP\Capability\IManager at DIContainer
* Add register capabilities to appframework
* Register capabilities in DI way
* Make unit test pass again
* Remove CapabiltiesManager from OCP
In case encryption was not enabled, we accidently set encrypted = 1 for
files inside mount points, since 8.1.0. This breaks opening the files in
8.1.1 because we fixed the code that checks if a file is encrypted.
In order to fix the file, we need to reset the flag of the file. However,
the flag might be set because the file is in fact encrypted because it was
uploaded at a time where encryption was enabled.
So we can only do this when:
- Current version of ownCloud before the update is 8.1.0 or 8.2.0.(0-2)
- Encryption is disabled
- files_encryption is not known in the app config
If the first two are not the case, we are save. However, if files_encryption
values exist in the config, we might have a false negative here.
Now if there is no file with unencrypted size greater 0, that means there are
no files that are still encrypted with "files_encryption" encryption. So we
can also safely reset the flag here.
If this is not the case, we go with "better save then sorry" and don't change
the flag but write a message to the ownCloud log file.
This removes the hard-dependency on output buffering as requested at https://github.com/owncloud/core/issues/16013 since a lot of distributions such as Debian and Ubuntu decided to use `4096` instead of the PHP recommended and documented default value of `off`.
However, we still should encourage disabling this setting for improved performance and reliability thus the setting switches in `.user.ini` and `.htaccess` are remaining there. It is very likely that we in other cases also should disable the output buffering but aren't doing it everywhere and thus causing memory problems.
Fixes https://github.com/owncloud/core/issues/16013
This Pull Request introduces a SabreDAV plugin that will block all older clients than 1.6.1 to connect and sync with the ownCloud instance.
This has multiple reasons:
1. Old ownCloud client versions before 1.6.0 are not properly working with sticky cookies for load balancers and thus generating sessions en masse
2. Old ownCloud client versions tend to be horrible buggy
In some cases we had in 80minutes about 10'000 sessions created by a single user. While this change set does not really "fix" the problem as 3rdparty legacy clients are affected as well, it is a good work-around and hopefully should force users to update their client
