This reverts commit 3731b2a006eca1e96d4087212a5e779c85a002e4.
Revert "[tx-robot] updated from transifex"
This reverts commit 94d91113f1206161b00bbc28da00aaf80bcd0a3e.
Revert "[tx-robot] updated from transifex"
This reverts commit e7cc8bac1e.
Revert "[tx-robot] updated from transifex"
This reverts commit 59fc3ff45a.
Revert "[tx-robot] updated from transifex"
This reverts commit 6a89a63d2e.
Revert "[tx-robot] updated from transifex"
This reverts commit b0bad03234.
* Move background job registration of Federation to info.xml
* Move background registration of Files app to info.xml
* Move background job registration of files_sharing to info.xml
* Move background job registration of files_trashbin to info.xml
* Move background job registration of files_versions to info.xml
* Move background job registration from user_ldap to info.xml
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.
$view->getUidAndFilename($filename); returns the federated cloud id in case of
a federated share. But in this case we need the local user who "owns" the file
which is the current logged in user in case of a federated share
