[BUG] CBX reader picks the unpacker by file extension, ignoring the archive type BookLore already detected

[reynikman]

Version: v2.3.1 (also present on develop as of today)

Summary

CbxReaderService selects the unpacker purely from the file extension, even though BookLore already detects the real archive type from magic bytes at scan time and stores it in book_file.archive_type. Any comic whose extension disagrees with its content is therefore unreadable, while the library UI shows it as a perfectly normal book.

In my library this affects 3,982 of 22,772 books — ZIP archives distributed as .cbr are extremely common in comic torrents/scan packs, and a few 7-Zip ones too.

Where

booklore-api/src/main/java/org/booklore/service/reader/CbxReaderService.java

private CachedArchiveMetadata scanArchiveMetadata(Path cbxPath) throws IOException {
    String filename = cbxPath.getFileName().toString().toLowerCase();
    ...
    if (filename.endsWith(CBZ_EXTENSION)) {
        return scanZipMetadata(cbxPath, lastModified);
    } else if (filename.endsWith(CB7_EXTENSION)) {
        ...
    } else if (filename.endsWith(CBR_EXTENSION)) {
        List<String> entries = getImageEntriesFromRar(cbxPath);   // <-- ZIP lands here
        ...

streamEntryFromArchive(...) a few lines below dispatches the same way.

So a ZIP named *.cbr goes to getImageEntriesFromRar → junrar throws → the unrar CLI fallback also fails (it is not a RAR) → IOException → ApiError.FILE_READ_ERROR. Same for a RAR named *.cbz.

Meanwhile ArchiveUtils.detectArchiveType(File) already does exactly the right thing (ZIP/RAR/7z magic, extension only as a last-resort fallback), and its result is persisted — book_file.archive_type in my DB is ZIP for every one of those .cbr files. The reader just never looks at it.

Reproduce

1. Take any CBZ, rename it to .cbr, put it in a library, scan.
2. The book appears normally; book_file.archive_type is correctly ZIP.
3. Open it in the web reader, or call GET /api/v1/cbx/{id}/pages — read error.
4. Through the Komga-compatible API the failure is quieter: pages are listed (that list comes from book_metadata.page_count), but every /komga/api/v1/books/{id}/pages/{n} returns nothing usable, so clients like Mihon show a blank chapter.

Suggested fix

Dispatch on the detected type rather than the name, e.g. in scanArchiveMetadata / streamEntryFromArchive:

ArchiveUtils.ArchiveType type = ArchiveUtils.detectArchiveType(cbxPath.toFile());
switch (type) {
    case ZIP -> ...
    case RAR -> ...
    case SEVEN_ZIP -> ...
    default -> throw new IOException("Unsupported archive format: " + cbxPath.getFileName());
}

detectArchiveType already falls back to the extension when the magic bytes are unreadable, so this is strictly more permissive than the current behaviour and needs no migration — archive_type is stored per file but re-detecting is one 8-byte read and the result is cached alongside the entry list anyway.

Workaround for anyone hitting this now

Rename the files so the extension matches the content (ZIP → .cbz, RAR → .cbr, 7z → .cb7) and update book_file.file_name in the same transaction so BookLore keeps pointing at the existing rows. The library watcher handles it gracefully on its own too: handleFileDelete parks the row in PendingDeletionPool for 8 s and handleNewBookFile matches it back by hash via recoverBook, so read progress survives.