desktop-packages team mailing list archive

[Misaki <1443809@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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
GsettingsChanges:
 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)

** Affects: nautilus (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1443809

Title:
  Failed thumbnail check not working properly

Status in nautilus package in Ubuntu:
  New

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
  GsettingsChanges:
   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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443809/+subscriptions