Support

Thank you for the log file!

This is what I thought was going on. You have a 32-bit version of PHP which internally uses 32-bit signed integers. The PHP hash functions in PHP 7.4 and later return 32-bit unsigned integers which are internally converted to floats in PHP. Because of the way the conversion works you may end up with an invalid conversion which results in the error you experienced.

As I mentioned, this is a change in PHP 7.4 and later. Before that, the behaviour of PHP's hash functions was platform-specific which is why 32-bit versions of PHP worked fine with Akeeba Backup all those years. The behaviour change is implied by the wording of a footnote of PHP's pack() function and another note in the description of the PHP hash extension. Luckily, I had a suspicion about it so I was able to figure out what happened.

I have rewritten the CRC32 calculation to not use any intermediate conversion to integer. I am now asking PHP to return binary strings and use them directly.

Please install the latest dev release       Version 9.3.3-dev202209291147-rev945be75    and take a new backup. It should now work. If not, please ZIP and attach the new log file.

No, you can install the new version on top of the old one. You never have to uninstall the already installed version to upgrade; you only need to do that if you want to downgrade.

I need your backup log file. Without it all I can tell you is that I cannot reproduce this issue taking a backup on any site, l local or live, I have access to.

I suspect that it's ultimately down to the fact that you are using a 32-bit version of PHP which most likely results in the CRC32 for approximately half of the files being calculated wrong in PHP itself (NOT our code). I am afraid that you belong in a stark minority. Breaking our software for 99.99% of our users to have it work for the 0.01% you belong to is not something I am willing to do, nor is it a reasonable expectation.

Further to that and as documented, you can tell your archive extraction software to ignore CRC32 errors and extract the ZIP archive just fine.

Beyond that there is nothing else I can do to help you.

I realised I forgot to tell you something very important. I took backups using the dev release I sent you on Joomla 4.2 and PHP 8.0 and 8.1 on the following environments: macOS (64-bit PHP, FastCGI), Ubuntu Linux 22.04 (64-bit PHP, FastCGI Process Manager a.k.a. FPM) and Windows 11 (64-bit PHP, FastCGI). All backups were tested with 7-Zip 19.00 (x64) running on Windows 11 and BetterZip on macOS (BetterZip internally uses 7-Zip command line, as it can be seen in its transcript). I did two tests with each archive: 1. extracting it and 2. using the Test feature in 7-Zip and BetterZip (Test checks the CRC-32 sums of each files; I was using that as I was refactoring the code to make sure I didn't break CRC-32 calculation).

In all of those tests the archives were extracted without warnings and the CRC-32 calculations were right.

I am going to see if I can install a 32-bit version of PHP on my Windows machine (I already tried on the Linux virtual machine and failed; my Apache is 64-bit) to reproduce your issue. I have a VERY strong suspicion that since the hash() and hash_file() functions are part of PHP itself they rely on the intrinsic, platform-specific integer type used by PHP. On the 64-bit builds it's a signed 64-bit integer which can fit the unsigned 32-bit CRC-32. On 32-bit builds it's a signed 32-bit integer which will most likely result in integer overflows. Also keep in mind that the PHP maintainers have deprecated 32-bit builds and will very likely drop support for 32-bit build altogether come PHP 9 -- while there is no official announcement, there was a very strong feeling against 32-bit build a few years ago when they started deprecating legacy code in the PHP core language itself.

What I am trying to say is that I am NOT trying to be difficult here. There's ultimately a hard limit of what I can do when PHP itself doesn't let me do it. I can't write a CRC-32 calculation in pure PHP. I mean, I could, but it'd be so desperately slow that backups which used to take seconds would now take hours to complete if they didn't time out outright. Hence the hard limit of what I can do.

I installed a 32-bit version of PHP on Windows 11 (PHP 8.0.24 x86 Non Thread Safe, downloaded from the official PHP site https://windows.php.net/downloads/releases/php-8.1.11-nts-Win32-vs16-x86.zip). I took a ZIP backup and tested it with 7-Zip as above. It extracts and test fine, without any CRC-32 errors.

At this point I think that the problem lies entirely on your server, assuming that the information I have gotten from you is correct.

Would it be possible to give me Super User and FTP access to your site so I can run a few more tests directly on your server to make sure that a. what we are testing is a new ZIP archive created after the changes I made yesterday and b. that the code installed on your site is indeed the modified code from yesterday? I can also come up with a few small tests which will tell me if your server produces correct CRC32 checksums for known strings and files, as compared to what 7-Zip and the Linux crc32 binary (part of libarchive-zip-perl) produce. This will tell us for sure where the problem lies.

As I said, the problem seems to be on your server. Akeeba Backup is now using PHP's built-in hash and hash_file functions to calculate the CRC32 sum. We set the third parameter ($binary) to true to get the raw CRC32 calculated by PHP itself as a binary string and put it verbatim into the backup archive.

The reason we need to do that is the big warning text found in PHP's crc32 documentation page. Basically, the old crc32() function works differently on 64-bit versions of PHP than it does on 32-bit versions which means we could not have common code for two versions. As they say at the end of this big warning, the right way to do it is using hash() (and hash_file() for file content) using the crc32b algorithm. Which, as I said, is what we do.

The problem here is that your server's PHP binary returns the wrong CRC32 checksum. I want to find out why. 

If you don't want to give me access to your site I am happy to leave it as it is. You have a broken server. I am most definitely NOT obliged to help you any further than explaining the root cause of your issue, per our Terms of Service, something I have already done. As far as my obligations towards you go I have fulfilled them to the fullest extent and gone above and beyond in a major way.

If you give me access to your site I might find a way to work around the problem on your server. It is unlikely but at the very least I can give you short reproduction code that you can take to your host and ask them to fix their server or refund you the hosting cost. As I said, if you don't want me to do that, no problem. I won't object for not having to do any more work that's well outside the scope of our support.