After trying to open a .cbr file which was previously opened without error, i only got the message that the file couldn't be opened. I checked my package install history and there was a recent unrar upgrade to version 1:5.0.12-1. Okular can't open all tried .cbr files if this version is installed. As a temporary workaround i downgraded unrar to the previous version 1:4.2.4-1 which solved the issue. Note that there only seems to be a problem with unrar, since i didn't had to downgrade libunrar as well, which is currently at version 1:5.0.12-1. Reproducible: Always Steps to Reproduce: 1. Install unrar version 1:5.0.12-1 2. open a .cbr file with okular 3. Error Actual Results: No file opened. Error Message received, stating that the file couldn't be opened. Expected Results: Opened and shown the file's contents.
Works here with openSUSE unrar package (unrar-5.0.11-2.1.5.i586). > unrar --version UNRAR 5.00 freeware Copyright (c) 1993-2013 Alexander Roshal Please add the output of "unrar --version". Could you also please enable all messages with "kdebugdialog" in Konsole, and add the output from Okular when trying to open the .cbr?
As for unrar: $ unrar --version UNRAR 5.00 freeware Copyright (c) 1993-2013 Alexander Roshal And the complete debugging information for okular. $ okular comic.cbr okular(28727)/kdeui (KIconLoader) KIconTheme::KIconTheme: Icon theme "Faenza" not found. okular(28727)/kdeui (KIconLoader) KIconTheme::KIconTheme: Icon theme "Faenza" not found. okular(28727)/kdeui (KGlobalAccel) KActionCollection::addAction: Registering action "go_first" under new name "first_page" okular(28727)/kdeui (KGlobalAccel) KActionCollection::addAction: Registering action "go_last" under new name "last_page" okular(28727)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-schuck/ksycoca4" okular(28727)/kdeui (KGlobalAccel) KActionCollection::addAction: Registering action "file_save_as" under new name "file_save_copy" okular(28727)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(28727)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(28727)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(28727)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(28727)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: INotify available: true okular(28727)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(28727)/kdeui (KMainWindow) KMainWindow::applyMainWindowSettings: KMainWindow::applyMainWindowSettings "MainWindow" okular(28727)/kdeui (KMainWindow) KMainWindow::applyMainWindowSettings: KMainWindow::applyMainWindowSettings "MainWindow" okular(28727)/kdeui (KMainWindow) KMainWindow::applyMainWindowSettings: KMainWindow::applyMainWindowSettings "MainWindow" okular(28727)/kdeui (KMainWindow) KMainWindow::applyMainWindowSettings: KMainWindow::applyMainWindowSettings "MainWindow" okular(28727)/kparts KParts::ReadWritePart::setModified: setModified( false ) okular(28727)/kparts KParts::ReadWritePart::setModified: setModified( false ) okular(28727)/kdecore (trader) KMimeTypeTrader::query: query for mimeType "application/x-cbr" , "okular/Generator" : returning 1 offers okular(28727) UnrarHelper::UnrarHelper: detected: "/usr/bin/unrar" ( "unrar-nonfree" ) okular(28727)/kdecore (kdelibs) KTempDir::create: KTempDir: Temporary directory created : "/tmp/kde-schuck/okularBrhf3s/" okular(28727)/kdecore (trader) KMimeTypeTrader::query: query for mimeType "application/x-rar" , "okular/Generator" : returning 0 offers okular(28727)/kdeui (KNotification) KNotificationManager::notificationClosed: 467 okular(28727)/kparts KParts::ReadWritePart::setModified: setModified( false ) okular(28727)/kparts KParts::Part::~Part: deleting widget Sidebar(0x1944770) "" okular(28727)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: INotify available: true The funny thing is it detected unrar correctly it just fails to open and display the file. I have even considered that a wonky build has managed to enter the repositories and rebuild unrar locally. To no avail. It still fails to open with the current version under Arch.
Can you attach on of the cbr you use for opening it? Does not seem like this bug should not be file dependant but better to make sure
Created attachment 82709 [details] Sample comic file that will open for me. This file will open for me. The base .rar file used DOESN't have the image in a sub-folder.
Created attachment 82710 [details] This is a sample file that won't open for me. This file fails to open. It HAS the image in a subfolder within the file.
Seems like it has something to do with the files. If the images are contained in a subfolder within the rar file used as base for the .cbr okular fails to open it with the latest unrar version.
I dug a little deeper. Seems like the problem essentially comes from line 131 in generators/comicbook/unrar.cpp > startSyncProcess( QStringList() << "lb" << mFileName ); The unrar lb command changed its behavior in the current version. I get the following outputs for the error-sample: >$unrar | head -n 2 ; unrar lb error2.cbr > >UNRAR 4.20 freeware Copyright (c) 1993-2012 Alexander Roshal >Error.jpg >error2 > $unrar | head -n 2 ; unrar lb error2.cbr > >UNRAR 5.00 freeware Copyright (c) 1993-2013 Alexander Roshal >error2/Error.jpg >error2 The current version is now listing the containing folder as well as the image. Because of this, the list() function in unrar.cpp can't find any of the extracted images and returns an empty QStringList. Seems like line 117 in generators/comicbook/unrar.cpp needs to be > int ret = startSyncProcess( QStringList() << "x" << mFileName << mTempDir->name() ); for unrar version 5+.
Thanks for the test files. The only .cbr files I had did not use sub-directories. Patch is at https://git.reviewboard.kde.org/r/113163
> Seems like line 117 in generators/comicbook/unrar.cpp needs to be > > int ret = startSyncProcess( QStringList() << "x" << mFileName << mTempDir->name() ); > for unrar version 5+. That would also be possible, but I am not sure, if Okular handles nested directories for the temporary extracted files everywhere (e.g. when later cleaning up etc.). Also, I am not sure how unrar behaves when absolute paths are present in the archive.
Agreed. Your patch is quite elegant and superior to my suggestion.
Just finnished compiling. Works on my end.
Thanks for testing, but we resolve the bug, when the commit was made :)
Whoops. Sorry for that.
Git commit cfa37065c26ac2a8ece558680a31be4e4bad7091 by Albert Astals Cid, on behalf of Christoph Feck. Committed on 13/10/2013 at 21:54. Pushed by aacid into branch 'KDE/4.11'. Fix cbr (rar) listing with unrar 5 The new unrar version includes the paths in its "bare listing" (unrar lb), while it still extracts only the filename without the path. Thus, the Unrar::list() function fails. This patch strips the path away. REVIEW: 113163 FIXED-IN: 4.11.3 M +6 -2 generators/comicbook/unrar.cpp http://commits.kde.org/okular/cfa37065c26ac2a8ece558680a31be4e4bad7091