The ownCloud update routine also runs the "updateHtaccess" code in case only an application gets updated. This leads to having entries multiple time in the .htaccess file leading to unpredictable behaviour.
With 9.0 we added the "#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####" entry to the .htaccess file, this change uses it to ensure that only to the .htaccess gets written if the file has not been modified already. Since the .htaccess modifications are optional this is not a big deal.
Without this change updates of applications can break the rewrite rules (ending in endless redirects) as well as breaking the code integrity checker.
PATH_INFO will be empty at this point and thus the logic in base.php did not catch this. Changing this to "getRawPathInfo" will ensure that the path info is properly read.
Fixes https://github.com/owncloud/core/issues/23199
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.
OC_Utils::checkServer makes an unnecessary call to $config->getSystemValue('installed', false), which replicates the call made immediately before it during the call to needUpgrade.
The phpdoc for the sharing functions was very restrictive. As a
consequence passing node object (for example from the OCS Share API
where we don't really care if it is a file or folder), would actually
be invalid.
With this loser restriction the interfaces become more generic.
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
This introduces the defacto standard PSR-4 autoloader from composer into
core. This will allow proper PSR-4 naming of our classes.
Since our original autoloader is still available we can slowly switch
over classes to PSR-4.
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
Jenkins for ownCloud
Lukas Reschke
Morris Jobke
Manish Bisht
Thomas Müller
Robin McCorkell
Robin Appelman
Roeland Jago Douma
Phiber2000
Joas Schilling
David Baucum
Vincent Petry
C. Montero Luque
Arthur Schiwon