Failed thumbnail check not working properly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-desktop |
New
|
Undecided
|
Unassigned | ||
nautilus (Ubuntu) |
New
|
Low
|
Unassigned |
Bug Description
This is related to the gnome-thumbnailer code which is part of Nautilus. However, I don't know enough about programming to fix it myself.
If a failed thumbnail exists for a file, or specifically a universal resource identifier, Nautilus will not try to create a valid thumbnail for it, unless a non-failed thumbnail also exists for that URI/path.
Steps to replicate:
1) Create a new, blank document named image.jpg
2) make sure the failed thumbnail has been created, such as by restarting nautilus with 'nautilus --quit'
3) navigate back to that folder, rename or delete the blank file, and rename another image to image.jpg.
Result: no thumbnail will be created for the image.
When I was checking the thumbnail code for an unrelated issue (256x256 thumbnails take up too much space as PNG, sometimes larger than original file), I also saw enough to be able to investigate this issue a little. In the code for Nautilus, or gnome-thumbnailer, that I looked at, it appeared that the code was doing a check to see if the failed thumbnail was valid.
That is, if the modification time of the file as recorded in the PNG Chunk data does not match, it probably shouldn't count as a match for the file. But either it is incorrectly matching, or something else is wrong.
While testing for an unrelated issue that seemed like it might no longer exist, I found that as Firefox saves an item by creating a placeholder and then saving the actual file using a .part suffix (unless changed in options probably), it leads to this bug.
ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.
ProcVersionSign
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelMo
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 00:40:58 2015
GsettingsChanges:
b'org.
b'org.
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in nautilus (Ubuntu): | |
importance: | Undecided → Low |
I may have misfiled this, but not quite sure which project is responsible. I also note that when adding gnome-desktop to the list of affected projects, it said "gnome-desktop does not use Launchpad to track bugs. Nobody will be notified about this issue."
Added a screenshot of an image not being thumbnailed.
The relevant function seems to be "gnome_ desktop_ thumbnail_ factory_ has_valid_ failed_ thumbnail ()" /developer. gnome.org/ gnome-desktop/ stable/ GnomeDesktopThu mbnailFactory. html#gnome- desktop- thumbnail- factory- has-valid- failed- thumbnail
https:/
This is old code because I don't know how to reference the latest code: sourcecodebrows er.com/ gnome-desktop/ 2.32.0/ gnome-desktop- thumbnail_ 8h.html# ab9946e68564185 72e55147637a149 3ab
http://
It includes this:
pixbuf = gdk_pixbuf_ new_from_ file (path, NULL);
g_free (path);
if (pixbuf) thumbnail_ is_valid (pixbuf, uri, mtime); object_ unref (pixbuf);
{
res = gnome_desktop_
g_
}
g_checksum_free (checksum);
It mentions mtime, yet evidently that is not being checked if the process described in this report can cause a new thumbnail to fail to be generated.
As implied in the original report, if there is a valid thumbnail and also a failed thumbnail for the same path to a file, if the valid thumbnail doesn't match the mtime of the actual file, a new thumbnail will be generated. So it seems to work unless no 'normal' thumbnail (whether normal or large-sized) already exists.