There might be the case that `fopen($file, 'r')` returns false and thus ownCloud might believe that the config file is empty and thus potentially leading to an overwrite of the config file.
This changeset introduces `file_exists` again which was used in ownCloud 5 where no such problems where reported and should not be affected by such problems.
Ref https://github.com/owncloud/core/issues/12785#issuecomment-71548720
The permissions are already catched properly on the installation so we just have to check whether the file is readable to prevent fatal errors from happening.
Fixes https://github.com/owncloud/core/issues/12135
Issue #9885 appears to be triggered by ownCloud invalidating the entire
PHP opcache. Testing indicates it can be avoided by only invalidating the
single file that was written from the opcache, instead of clearing the
whole thing. In general it is more efficient to invalidate only the single
file that was changed, rather than the whole cache.
This adds a deleteFromOpcodeCache() function which invalidates a single
file from the opcache if possible, returning true if the underlying
function returns true (which may mean 'success', or 'file does not exist',
or 'file exists but is not in opcache', all of which are OK to treat as
good for our purposes). It also changes writeData() in config.php to try
using deleteFromOpcodeCache() and only fall back on clearOpcodeCache() if
that fails.
This adds a file lock to the config in hope that this prevents race conditions as reported in https://github.com/owncloud/core/issues/11070
Testplan:
- [ ] Delete config.php and make it read-only => Error is thrown that it is not writeable
- [ ] Installation still works
- [ ] Changing config settings works (i.e. using the SMTP config switches in the administration menu)
- [ ] Your PC didn't blow up
- [ ] Installing the news app and the "Disable AppCode checker" app did not destroy your installation
Only skip the main config
Otherwise read only additional configs might not be processed
Test on tmpdir
