[Bug]: Updater backups don't support symlinks

[jplitza]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

When running the updater, it backups symlinked files multiple times.

Steps to reproduce

1. Install the "recognize" app
2. Download the models and everything to make it ready to run
3. Update Nextcloud
4. The updater creates a backup, which contains three copies of the 400 MB file apps/recognize/node_modules/@tensorflow/tfjs-node-gpu/deps/lib/libtensorflow.so.2.9.1 in its symlinks apps/recognize/node_modules/@tensorflow/tfjs-node-gpu/deps/lib/libtensorflow.so.2 and apps/recognize/node_modules/@tensorflow/tfjs-node-gpu/deps/lib/libtensorflow.so

Expected behavior

apps/recognize/node_modules/@tensorflow/tfjs-node-gpu/deps/lib/libtensorflow.so.2.9.1 is only backed up once, and the symlinks are preserved as such.

Installation method

Community Manual installation with Archive

Nextcloud Server version

27

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[joshtrichards]

Agreed. The cause is likely here:

updater/lib/Updater.php

Lines 449 to 452 in b0d2bc6

	// If it is a file copy it
	if ($fileInfo->isFile()) {
	$state = copy($fileInfo->getRealPath(), $backupFolderLocation . $fileName);
	if ($state === false) {

isFile() is resolving the target of the symbolic link. Need to add an isLink() check with additional handling for symbolic links in the backups.

[joshtrichards]

In the mean time, using --no-backup may be a workaround.