[suggested fix] generated autoloader suffix causes integrity check to fail after interrupted update 10.0.9.5 -> 10.0.10.4

[gnanet]

composer dynamically generated suffix causes integrity check fail after update

only exception to this was ClassLoader.php by 2 whitespace added

$search = $subPath . '\\';

A possible way to fix

Specify an integrity-check-safe autoloader-suffix in composer.json

Steps to reproduce

1. Installed ownCloud version 10.0.9.5
2. Receive update notification
3. Start update from web 10.0.9.5 -> 10.0.10

Expected behaviour

Integrity check should not complain

Actual behaviour

Integrity check complains:

- core
	- INVALID_HASH
		- updater/vendor/autoload.php
		- updater/vendor/composer/autoload_real.php
		- updater/vendor/composer/autoload_static.php
		- updater/vendor/composer/ClassLoader.php

Server configuration

Operating system: Debian GNU/Linux 7.11 (wheezy) - Linux oc 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64

Web server: Apache/2.2.22 (Debian) fpm-fcgi

Database: MySQL 5.5.60

PHP version: 7.2.9 fpm (packaged for wheezy by Plesk)

ownCloud version: 10.0.10.4 Community

Updated from an older ownCloud or fresh install: Update / 10.0.9.5

Where did you install ownCloud from: https://owncloud.org/download/#owncloud-server-tar-ball

Signing status (ownCloud 9.0 and above):

https://gist.github.com/gnanet/5e47544c44599000e6618a28cf697138

The content of config/config.php: not relevant

List of activated apps: not relevant

Are you using external storage, if yes which one: not relevant

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #27139 (Integrity check fails after update to 9.1.4 due to stray .gitignore files), #30229 (Integrity check fail after updating 10.0.3 -> 10.0.4), #23769 (Integrity check always fails), #32388 (Failed update to 10.0.9), and #4404 (Upgrade from 5.0.9 -> 5.0.10 failed).

[PVince81]

strange. in our update tests we did not observe this.

@VicDeo

[gnanet]

My conlclusion is only based on the diffs i made from the running system and the content i could download from owncloud.org as owncloud-10.0.10.tar.bz2
It shown clearly that no functional difference was present, only notable change was the autoloader-suffix, and so i came to the idea:

If it is possible to avoid the unnecessary change of that suffix, it can also help to avoid integrity issues on upgrades on long term, and if that suffix is only changed/updated if you also intend to change the related functionality, and the integrity hashes are updated too, this issue at least would never come back

[gnanet]

Quick check on the hashes shows that somehow the updater did not update these files itself (but still have to note, their missing-update would only be an issue if these files would functionally differ, and not only the autoloader-suffix):

owncloud-10.0.9.tar.bz2/utar://owncloud/core
"updater/vendor/autoload.php": "98c7ab081074455dd96fa8201393ea980e9aa5328fd05a9a50fba4875a4412baab67f03f59b3979b39f00da75bab22c6304e9ba5e3c648d4077bc30a5442d01d",

owncloud-10.0.10.tar.bz2/utar://owncloud/core
"updater/vendor/autoload.php": "b950ee94c37c54342fd58e22700fb15658d117d5333817b10ee4f85cb202cca8e96b7eb8e057576e838ecfad1844bc4ad4794d35a3f5271332b0828a25c4da46",

[VicDeo]

mhm. As usual I used webupdater to migrate from 10.0.9 to 10.0.10 for my private instance and everything is ok with integrity there.
Probably moving updater files was terminated before completion.

[gnanet]

@VicDeo yes my assumption is the same, but surprizing that only these files were left, also i found no evidence to my assumed timeout.

update.log from the datadir (which could really use a timestamp :D )

[info] Execution of upgrade:detect command started
[info] ownCloud 10.0.9.5 found
[info] Execution of upgrade:detect command stopped. Exit code is 0
[info] Execution of upgrade:checkSystem command started
[info] Execution of upgrade:checkSystem command stopped. Exit code is 0
[info] Execution of upgrade:checkpoint command started
[info] Execution of upgrade:checkpoint command stopped. Exit code is 0
[info] Execution of upgrade:detect command started
[info] ownCloud 10.0.9.5 found
[info] Execution of upgrade:detect command stopped. Exit code is 0
[info] Execution of upgrade:executeCoreUpgradeScripts command started
[debug] Replacing 3rdparty
[debug] Replacing config
[debug] Replacing core
[debug] Replacing l10n
[debug] Replacing lib
[debug] Replacing ocs
[debug] Replacing ocs-provider
[debug] Replacing resources
[debug] Replacing settings
[debug] Replacing .htaccess
[debug] Replacing .mailmap
[debug] Replacing .tag
[debug] Replacing .user.ini
[debug] Replacing AUTHORS
[debug] Replacing CHANGELOG.md
[debug] Replacing console.php
[debug] Replacing COPYING
[debug] Replacing cron.php
[debug] Replacing db_structure.xml
[debug] Replacing index.html
[debug] Replacing index.php
[debug] Replacing indie.json
[debug] Replacing occ
[debug] Replacing public.php
[debug] Replacing remote.php
[debug] Replacing robots.txt
[debug] Replacing status.php
[debug] Replacing version.php
[info] Execution of upgrade:executeCoreUpgradeScripts command stopped. Exit code is 0

[VicDeo]

@gnanet 'executeCoreUpgradeScripts' does not replace files in updater, there is a separate command for this, the very last one:
https://github.com/owncloud/updater/blob/master/src/Command/PostUpgradeCleanupCommand.php#L62

[gnanet]

@VicDeo This confirms my assumption: the update was interrupted, but for my luck not at an inconsistent state. Thank you!

I think the issue was investigated deep enough, and i know now the cause, so i think i close it.

This does not affect my suggestion: if the autoloader does not change in function, why not prevent the regeneration of the suffix, which makes the integrity hash unnecessarily changing

If my idea is worth discussing further, i can open a separate issue later.

[skupjoe]

I'm getting integrity hash issues after using the updater to move from ownCloud 10.0.0.6 > 10.0.1.0

I even got the latest tar and performed an rsync --update and I'm still seeing these errors.

Any fix?