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.
Fixes#23536
The new sharing code is much stricter in checking permissions. However
for non moveable mounts the permissions UPDATE+DELETE are not reported
on the mount point.
This is just a quick fix.
* Updated unit tests
In 9.0 we converted the old shares to the new shares. So for 9.1 we can
savely remove the fallback code.
This code was required when there was no initiator set.
* Fixed unit tests
The old behaviour was that only languages could be used for an app
that are already present in the apps/$app/l10n folder. If there is
a themed l10n that is not present in the apps default l10n folder
the language could not be used and the texts are not translated.
With this change this is possible and also the l10n files are
loaded even if the default l10n doesn't contain the l10n file.
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
A PreconditionNotMetException must only be thrown if explicit
preconditions are specified for setValues(), not if the value is merely
the same as was already in the DB.
The setup uses `\OCP\IRequest::getInsecureServerHost` which in some cases can also include a port. This makes the trusted domain check fail thus.
I've decided to add this here that way because adjusting the setup would require parsing the host properly. This is not something that can be done very good in PHP. Check the following example for why `parse_url` is not our friend: https://3v4l.org/k501Z
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.
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.
Incomming federated shares are a special kind. We mount them as normal
webdav shares but we do supply owner info with the federated cloud id of
the share owner.
Since we do not yet have the new resharing behaviour on federated shares
we need to set the correct owner. Which will allow sharing and proper
mounting for other users.
fixes#22500
Fixes#22119
Just try to get the folder of the user. If it is not there a
NotFoundException will be thrown. Which will be handled by the avatar
endpoint.
Our issue template states that users should post the output of `/index.php/settings/integrity/failed`, at the moment it displays that all passes have been passed if the integrity checker has been disabled.
This is however a wrong approach considering that some distributions are gonna package Frankenstein releases and makes it harder for us to detect such issues. Thus if the integrity code checker is disabled (using the config switch) it displays now: `Appcode checker has been disabled. Integrity cannot be verified.`
This is not displayed anywhere else in the UI except these URL used for us for debugging purposes.
Fixes#19685
The default expiration date should only be set when we create a new
share. So if a share is created and the expiration date is unset. And
after that the password is updated the expiration date should remain
unset.
