fix(config): Suppress config.php fopen error at install time

[joshtrichards]

• Resolves: [Bug]: Failed to open stream + Error while running background job immediately after installation #45671 (config.php error not the second one in that report)

Summary

The changes in #44230 brought back a regression from the OC days which is generating a non-operational error immediately after install time:

owncloud/core#13736
owncloud/core#21923

{"reqId":"58mbKNITzcU0stL3faUH","level":3,"time":"2024-09-26T19:52:18+00:00","remoteAddr":"","user":"ncadmin","app":"PHP","method":"","url":"--","message":"fopen(/var/www/html/config/config.php): Failed to open stream: No such file or directory at /var/www/html/lib/private/Config.php#190","userAgent":"--","version":"30.0.0.14","data":{"app":"PHP"},"id":"66f5bc6a0d035"}

It becomes the very first log entry you see after a new install. While harmless from a technical standpoint, it is needless to say, not a great way for someone to be introduced to Nextcloud right after installation. And it gives the impression something is wrong, when it really isn't.

Cause

At install time we use our onError error handler:

server/lib/base.php

Line 651 in 341b31b

set_error_handler([$errorHandler, 'onError']);

This handler lacks handling to exclude suppressors:

server/lib/private/Log/ErrorHandler.php

Lines 53 to 61 in 341b31b

	public function onError(int $number, string $message, string $file, int $line): bool {
	if (!(error_reporting() & $number)) {
	return true;
	}
	$msg = $message . ' at ' . $file . '#' . $line;
	$e = new Error(self::removePassword($msg));
	$this->logger->log(self::errnoToLogLevel($number), $e->getMessage(), ['app' => 'PHP']);
	return true;
	}

The easiest solution is simply to add back the file_exists() check here before we call fopen().

Additional thoughts

Despite this PR, I was tempted to add support in the onError handler for the suppressor. That way things behave in a standard way. If we want to suppress, it's been decided upon for a good reason. I took the approach here in this PR for now though because it seemed more conservative, by simply bringing back the file_exists() check and relying on that instead of the non-functioning suppressor. This PR should be sufficient though since there aren't currently any other known situations where the suppressor handling is an issue. If/when other spots with the suppressor pop up, we could reconsider.

TODO

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[joshtrichards]

/backport to stable30

[joshtrichards]

/backport to stable29

[joshtrichards]

/backport to stable28

[come-nc]

Either that or supporting the suppressor in onError is fine for me.
It’s really a pain that php fopen works like this -_-