On upgrade to 23.0.3: mail 1.11.7 hash remains invalid after rescan

After upgrade to 23.0.3, mail app version 1.11.7:

sudo -u www-data php occ integrity:check-app mail

    • vendor/sabberworm/php-css-parser/lib/Sabberworm/CSS/Rule/Rule.php:
      • expected: b92bdc5225a51189edcc9f1490d26dba10c440be56939037a39a7634e09488de91aa70d9c1d6dabae7387252553d84a1214a60af409ab86f7d8520bc3bc7b1ee
      • current: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e

Can nothing fix this? Otherwise NC is operating normally.

The usual answer is, download the related archive file, extract the mentioned file from the archive and replace the file in the given directory.

In this case, diff reports Rule.php distributed by NC matches Rule.php at PHP-CSS-Parser/Rule.php at master · sabberworm/PHP-CSS-Parser · GitHub

Where might the ‘official nextcloud’ version of this file be?

What about this archive file:


Thanks for that. I downloaded it and expanded it, there is no file there with the name Rule.php
Any other spot I might look?
root@www1:~/tmp/nextcloud# tar xvf nextcloud-23.0.3.tar.bz2
root@www1:~/tmp/nextcloud# cd nextcloud
root@www1:~/tmp/nextcloud# find . -name Rule.php -print

Ups, you’re absolutely right. I missed the fact that you’ve checked the mail app and that the mentioned component is part of it. You can try to download the mail app archive here: https://apps.nextcloud.com/apps/mail

Thanks for that. A better answer would be: as the system has so much
code to bring such problems to the attention of the users, why not take
the step of being so kind as to to provide the address of the ‘related
file’-- and if was really intending to be helpful, provide a command to
download and install it. Otherwise ‘normal mortals’ are expected to
know such things as determining the name of the related archive file,
finding the correct version of that online, downloading it, extracting
it, finding the particular file, then moving it into place. Sort of
blurs the line between ‘admin’ and ‘dev’ – we don’t usually want admin
folks moving source files into place in products we term ‘release’.

I’ve updated my system several times in the past and have run into that problem only once. Unfortunately I have no clue why this happens from time to time.

Thanks for the link, I found the right version of the right file then moved it into the right directory then rescanned and it passed. The ‘right version’ is a long way from the upstream version.

Of some interest, the latest version of that file upstream is 10215 bytes, the one in the nextcloud archive is 6520.

I think an app update ‘silently’ included the upstream version, but the scan crc was for an earlier rev-- so then the earlier rev ‘silently’ got put back into the nextcloud release. That’s the only explanation I can think of that made sense.

Moral of the story— wait at least a week before installing any update nextcloud mentions. Otherwise you are a late-rc-beta-tester – except not paid the big $$$…