Chevereto V4.5.9 is a maintenance release that addresses the SQL update bug affecting v3.20 to v4.2 and several other storage/queue related bugs.

This release follows the V4.5.8 security update and fixes bugs reported by users while upgrading. If you are coming from an older installation, especially one older than 4.2.0, this is the version you want to land on.

Upgrade fixes

Most of the issues reported after V4.5.8 came from installations upgrading from older versions:

• Database update failing on older installations. The update created the tag tables with their final structure and then tried to alter them again, and it also tried to drop a column that might not exist. These steps now check the database first and only run when needed.
• Installed version detection. A bug in the version detection caused some installations to report the system as not installed. All installations older than 4.2.0 were affected.
• Update check and news check. These checks were blocked on installations upgraded before 4.2.0.
• Null cipher values. Installations with encryption enabled that were upgraded from a version older than 4.2.0 could fail when handling null cipher values.

New updates check command

There's a new command for checking for available updates:

app/bin/cli -C updates-check

Storage fixes

The storage delete queue got a full review. One failure no longer stops everything else, files that are already gone count as deleted, and failed deletes are retried instead of being lost or retried forever.

• FTP folders. FTP folder errors were silently ignored, so missing date folders were never created. Files landed in the last existing folder and their URLs returned 404. Missing folders are now created, and if that fails the upload stops with an error.
• FTP errors. Errors now include the message from the FTP server. Failed deletes are logged and retried without blocking the queue.
• Local storage. If one file in a batch couldn't be deleted, the whole batch stopped. Each file is now deleted on its own.
• SFTP. Every file in a batch was marked as deleted, even when the delete failed. Now only files that were actually removed, or were already gone, count as deleted.
• S3. A file that failed to delete stayed in the queue without the attempt being counted, so it was retried forever. Each failure now counts as an attempt, the error is logged, and the file is marked as failed after a few tries.
• Azure, Backblaze B2, Google Cloud, FTP and OpenStack. One failed delete stopped the whole batch. Each file is now handled on its own. OpenStack now deletes files one at a time and only removes them from the queue once they're actually deleted.
• Alibaba OSS. The delete response wasn't handled correctly, so an unmatched entry could break the run and failed deletes were retried endlessly. Unmatched entries are now skipped, and failed deletes are retried until they're marked as failed.
• Unreachable storage. If one storage couldn't be reached, the delete queue stopped and files on every other storage were left waiting. The unreachable storage is now skipped and retried later.
• Error logging. Delete errors weren't recorded anywhere. The error from each storage is now written to the error log.

Other fixes

• Album privacy. Fixed album privacy filtering for liked images, a regression introduced in V4.5.8.
• Cron job locks. When a cron job failed, its lock wasn't released and the job was skipped until the lock expired. Locks are now always released when a job finishes, even if it fails.