in order to create a 1:1 copy of a file if a version gets created
we need to store this information on copyBetweenStorage(). This
allows us to by-pass the encryption wrapper if we read the source file.
The code path called when using external storage with WebDAV is using `\OC\Files\Storage\Wrapper\Encryption::getMetaData` which did not contain the actual encrypted version inside the cache entry version. This lead to the following:
1. User uploaded a file
2. File is created and `\OC\Files\Storage\Wrapper\Encryption::getMetaData` is called. It has an empty `encryptedVersion` but sets `encrypted` to either `true` or `false`.
3. The call when updating the file cache will use the old version.
In case of a move operation from an unencrypted to an encrypted
storage the old encrypted version would stay with "0" while the
correct value would be "1". Thus we manually set the value to "1"
for those cases.
See also https://github.com/owncloud/core/issues/23078
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.
Some move operations when cross-storage will be replaced by copy and
delete. Before attempting this, first check whether the source storage
has delete permissions.
This also prevents renaming system-wide external storages.
When overwriting shared files as recipient, the part file is written on
the uploader's storage before overwriting the target file.
If the uploader has no quota left, they should still be able to
overwrite that file with Webdav. To make this work, they need to be able
to write the part file to their own storage first.
The encryption code uses partial cache entries for the part file (which
are not stored in the database) but are useful for other parts of the
code to retrieve the file size again.
This means that in the fixed code $info was empty, so getData() could
not be called.
The fix makes sure to support both cases when the cache entry exists and
doesn't.
