Failed thumbnail check not working properly

Bug #1443809 reported by Misaki on 2015-04-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)

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.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 00:40:58 2015
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b"['name', 'size', 'date_modified', 'date_accessed', 'type']"
 b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions']"
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

Misaki (myjunkmail311006) wrote :
Misaki (myjunkmail311006) wrote :

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 ()"

This is old code because I don't know how to reference the latest code:

It includes this:

  pixbuf = gdk_pixbuf_new_from_file (path, NULL);
  g_free (path);

  if (pixbuf)
      res = gnome_desktop_thumbnail_is_valid (pixbuf, uri, mtime);
      g_object_unref (pixbuf);

  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.

Changed in nautilus (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers