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
The path attribute contains the path relative to the owner's home
folder, not the one from the recipient, which is useless for the client
and needlessly discloses the owner's original path.
The requested already has access to the full path of the file, so no
need to add it to the response.
* versionSize is calculated anyway in the expire job - > dropped
* offset/neededSpace was needed for expiry before the file is moved to the versions -> now this is included already in the currently used space because the expiry job is defered to a point in time after the version creation
* fixes#21108
Adding group Db to federation tests and ldap tests
Add group DB to Test_UrlGenerator
Adding group DB to trashbin and versions tests
Adding group DB to Test_Util_CheckServer for pg
Currently the `getPath` methods returned `NULL` in case when a file with the specified ID does not exist. This however mandates that developers are checking for the `NULL` case and if they do not the door for bugs with all kind of impact is widely opened.
This is especially harmful if used in context with Views where the final result is limited based on the result of `getPath`, if `getPath` returns `NULL` PHP type juggles this to an empty string resulting in all possible kind of bugs.
While one could argue that this is a misusage of the API the fact is that it is very often misused and an exception will trigger an immediate stop of execution as well as log this behaviour and show a pretty error page.
I also adjusted some usages where I believe that we need to catch these errors, in most cases this is though simply an error that should hard-fail.
