I already filed a GLib bug about this (kind of doing things backwards here), but I thought I’d bring it up here as well.
Since upgrading to GNOME 50.2 (Fedora 44), I noticed that evince-thumbnailer can no longer preview remote comic book archives (.cbr or .cbz files, which are really RAR and Zip files, respectively). It used to be able to, through GNOME 49, but since GNOME 50 attempting to generate the thumbnail manually results in an error:
$ evince-thumbnailer -s 256 "sftp://USER@HOST/tmp/testfile.cbr" /tmp/thumb.png
(evince-thumbnailer:665941): GLib-GIO-CRITICAL **: 21:39:54.657: GFileInfo created without standard::content-type
(evince-thumbnailer:665941): GLib-GIO-CRITICAL **: 21:39:54.657: file ../gio/gfileinfo.c: line 1841 (g_file_info_get_content_type): should not be reached
Error loading document: File type RAR archive (application/vnd.rar) is not supported
As you can see, the file is identified as a RAR file, which is true as far as it goes, but it should be identified as an application/x-cbr which it also is.
The reason for the misidentification turned out to be, as the CRITICALs there hint, a failure in Evince’s attempts to get the standard::content-type of the file. Because it doesn’t have one anymore.
Remote .cbr files on sftp:// volumes no longer return a standard::content-type value in Gio, even if queried for one. They only have a standard::fast-content-type. This is in contrast to, say, .pdf files which still have a standard::content-type, even remotely:
# CBR...
$ gio info "sftp:://user@host/tmp/testfile.cbr" | grep content-type
standard::fast-content-type: application/x-cbr
$ gio copy "sftp:://user@host/tmp/testfile.cbr" /tmp/testfile.cbr
$ gio info /tmp/testfile.cbr | grep content-type
standard::content-type: application/x-cbr
standard::fast-content-type: application/x-cbr
# PDF...
$ gio info "sftp://user@host/tmp/testfile.pdf" | grep content-type
standard::content-type: application/pdf
standard::fast-content-type: application/pdf
Is Evince doing something wrong? Does it need to start using the standard::fast-content-type for remote files? For all files?
And why would there be a standard::content-type for some files on a remote volume, but not others?