The SabreDAV release in 9.0 requires XMLReader, while this is usually compiled in by default some distributions like Gentoo don't.
Without this ownCloud gives a fatal 500 error instead of telling people to enable XMLReader.
Fixes https://github.com/owncloud/core/issues/23003
Fixes#22601
Before we did a full test on all chunks to verify if a chunked upload
was completed. This is unneeded since if we are missing one chunk we can
already fail.
Also we look from back to front since it is much more likely that we
find a missing chunk thus can error out early.
In the case of shared files, we have to call free_space() on the file
name. This has the side-effect that when uploading to a local storage
without quota set, it will call disk_free_space with the file name,
which fails.
This fix uses the parent folder in case the given path is a file.
* 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.
When calling `\OC\Files\View::copy` we should also keep the version to ensure that the file will always have the correct version attached and can be successfully decrypted.
To test this the following steps are necessary (from https://github.com/owncloud/core/issues/22781#issuecomment-191328982):
1. setup a new ownCloud 9.0 beta2
2. enable encryption
2. upload a docx (5.7MB large)
3. upload the same file again and overwrite the existing file
4. I can download the original file and the first version
5. I restore the first version
6. restored version can no longer be downloaded with the error described above
The manual cache operation in `\OCA\Files_Versions\Storage` is unfortunately necessary since `\OCA\Files_Versions\Storage::copyFileContents` is not using `\OCP\Files\Storage::moveFromStorage` in the case when an object storage is used. Due to the workaround added in 54cea05271 the stream is directly copied and thus bypassing the FS.
We should not scan any custom data directory in the integrity checker as well. Otherwise this would lead to a massive increased update time that may likely exceed the timeout.
To test this:
1. Install ownCloud 8.2.2, set as data dir another folder than `data` such as `data-asdf`. Make sure that folder lives in the web root as well.
2. Update that instance to 9.0.0 beta2 => Errors are shown in the code integrity check
3. Apply this patch and trigger the rescan in the admin settings => No errors are shown anymore (can also do a new update with that patch applied)
Fixes https://github.com/owncloud/core/issues/22698
Adds autodiscovery support to server-to-server sharing as specified in the specification. If no discovery data is found it is using the fallback ownCloud endpoints for legacy support.
Sharing of the users root folder should not be allowed as it is very
weird UX. Also many of our clients have no proper way of displaying
this.
Added unit test
Also added intergration tests to make sure we won't allow it in the
future.