Therefore what? Why is this a problem?

Are you kidding? When browsing through directories, who wants the file manager to freeze while some thumbnailer tries to extract 5+ GiB of data from any rar archive that might exist in that directory for nothing? Archive files aren't for thumbnailing!

People who don't want the thumbnailer to extract thumbnails from giant files, should disable the thumbnail view.

RAR archives are pretty often comic books in the ".cbr" format, and it is plenty realistic that a comic book is that size. And honestly I cannot imagine why one would want to have such a terrible format for any reason other than the requirement to put up with the restrictions of some document format.

My advice is to take advantage of your file browser's settings to disable thumbnail extraction for files over a certain size. I only have thumbnails for files that are less than 1MB in size.

I'm honestly clueless how you ever got this problem, since Atril has supported CBR comics since its very first commit in 2011 which imported the evince codebase.

You might want to investigate why your apparently-not-comic-book-archive RAR files are being detected as the freedesktop mimetype application/vnd.comicbook-rar or its deprecated alias application/x-cbr -- they're supposed to be bound to the .cbr file extension. I have no idea why that should suddenly change.

I've deleted your comment due to being incredibly rude to staff. Don't do that again or we'll happily ban you.

1) CBR comics are https://en.wikipedia.org/wiki/Comic_book_archive, which is a subcategory of https://en.wikipedia.org/wiki/E-book -- this is something trivial to google, so I suggest you try doing that first next time.

2) Okay, apparently atril's thumbnailer uses the generic "application/vnd.rar" instead of its subclass "application/vnd.comicbook-rar", so it is listing, and attempting to thumbnail, the wrong mimetype. This is a legitimate, and very recent, upstream bug.

3) Telling your file browser to not thumbnail files above a certain size is not a bad idea either way -- it is a workaround that will prevent faulty thumbnailer files from operating to excess ;) in addition to just prioritizing speed/responsiveness over thumbnails even for files which can be legitimately thumbnailed.

The issue comes from https://github.com/mate-desktop/atril/issues/341 which had an incorrect fix. I've commented there to point out the issue.

EDIT: Submitted https://github.com/mate-desktop/atril/pull/349

Caja is configured to not thumbnail anything above 10MiB, however it seems it didn't honor that setting in this case. I don't know why. As I said I didn't want to be rude. It was just that WTF moment of "Well, the plane crashed and the makers tell me it is expected behavior." How do you explain what should be obvious to everyone? – But ban me, happily if you want. It's not like I'm getting paid for contributing or reporting bugs here, devoting my free time to help the project. Of course I googled the comic book format after you mentioned it, but besides the fact that they also seem to be using rar compression for it, I couldn't see what made you think that this is in any way related to my report as I made it clear that this is about normal archives, even stated the affected mime type in the title of this report. You also said that RAR files are "pretty often comic books" which sounded like you were telling me, that atril's behavior is okay, because every other uses of that format are negligible, which would be ridiculous, since I never heard of those comic books and their use of the RAR format can just be a niche application at best.

It is a pretty obvious connection to CBR -- all three applications are designed to read rar-compressed CBR files. (Also in the communities I associate with, CBR ebooks are extremely common. Whereas I've never met a Linux user that wanted to use .rar for anything if they could get away with .tar.* instead. Even Windows users prefer .7z)
You stated that it suddenly started doing this -- I didn't know offhand the method it used to detect CBR files, but I did know that it's been supported for a very long time. I assumed either it should have always opened .rar files, or that it should have always opened .cbr files only.

Since I don't have atril installed, I checked xreader and evince instead (evince being the original project, and xreader being the cinnamon fork of atril), and noticed there was a dedicated mimetype. Evince had both of the correct mimetypes, xreader only had "application/x-cbr". Seemed clear to me it was using mimetype detection properly and it wasn't obvious to me that the faulty mimetype was actually in atril's source code. Turns out even after being linked to the gnome commit which did this right, the atril team decided to do something completely different -- that's pretty odd, TBH.

I'm sure you can figure out how your last sentence was incompatible with your claim of "No offence meant", and why I took offense.

Okay, "suddenly" was a bit misleading... after the last update. It took me some time to find out about the reason why there were suddenly some unrar processes running and filling up my hard drive. If you or even me think that rar is a good format doesn't matter here. :) In fact I'm not using it very often today, but have lots of old files sitting around. It has pretty good compression though. Of course I also fixed the problem by removing the offending mime type from my thumbnailer configuration file. But I decided on reporting this anyway, as it will be overwritten with the next update and this simply couldn't be intentional.

Thanks for the fix Eli. Until this is officially incorporated upstream, I've created a couple of patch files to build the current version with. The changes are reflected in package version atril-1.20.3-2.

The update today still had "application/vnd.rar" in "/usr/share/thumbnailers/atril.thumbnailer". I've now added it to my NoExtract key in /etc/pacman.conf for the time beeing...

>The update today still had "application/vnd.rar" in "/usr/share/thumbnailers/atril.thumbnailer".

I'm not really in the business of breaking from upstream, so I made patches according to the approved commit diff (https://github.com/mate-desktop/atril/commit/798757001016e5e02de545762fab0018f72ff086). If you are still having issues with atril, then I highly recommend opening an issue on the aforementioned Github page so that it can be handled appropriately by the developers themselves. Anything else is beyond the scope of what we do here.

>I've now added it to my NoExtract key in /etc/pacman.conf for the time beeing...

Good to know.

autotools is fun ;) you forgot to run autoreconf after patching configure.ac so the configure script never got updated with the fix.

BTW the fix is now merged to master as https://github.com/mate-desktop/atril/commit/1b951620b1f382d9ed1875ebb8c53c55257391bd

>autotools is fun ;) you forgot to run autoreconf after patching configure.ac so the configure script never got updated with the fix.

AHHH damn, I even ran autoreconf locally when I was manually testing the fix, but it never found its way into the PKGBUILD. ;)