Re: Problem with thumbnail mamagement for image files

["Diego Escalante Urrelo" <diegoe gnome org>]

On a side-note, it looks like nautilus doesn't generate thumbnails for
trash:/// obex:/// and others, no matter the preferences set in
nautilus.

Regression or intentional?

On 3/14/08, Jeffery Small <jeff cjsa com> wrote:
>
>  There is a problem with the current implementation of thumb.MTime that I
>  think should be addressed.  Here is an example of the problem.
>
>  I have a bunch of image files which I copy to a new directory:
>
>         cp  z_01.jpg z_02.jpg z_03.jpg z_04.jpg  newdir
>
>  Now, I go to the new directory and run gThumb which displays the images and
>  creates the corresponding thumbnails.  OK so far.  I decide that I want
>  to rearrange the files so I do some renaming.  For simplicity, let's just
>  say I decide to index them all forward by one number so that they now get
>  renamed:
>
>         z_02.jpg z_03.jpg z_04.jpg z_05.jpg
>
>  I'm doing this at the shell level with my own scripts which use mv(1) to
>  rename the files.  At this point I refresh (or restart) gThumb, but there
>  is a serious problem.  The thumbnails do not get updated to reflect the
>  current corresponding image files.  After further investigation, the reason
>  appears to be that the stat(2) time entries are only recording the st_mtime
>  values to the second.  When the copy operation is performed and the new
>  image files are initially created, most or all of them end up having the
>  same mtime value at one second resolution.  Later, when the files are
>  renamed, the mv(1) operation preserves the mtimes on the files and the new
>  z_02.jpg (old z_01.jpg) still has the same mtime as the old z_02.jpg (now
>  z_03.jpg) so gThumb fails to see a change in the mtimes and will never
>  update the thumbnail to reflect the new image file contents.  Needless to
>  say, this causes great confusion and a lot of problems.
>
>  There are two possible solutions to the problem:
>
>  The first would be to store mtimes to nanosecond resolution.  Apparently
>  this is possible as there is a recently added -E flag on my Solaris 10
>  system which allows the mtime/ctime/atime to be displayed in nanosecond
>  resolution.  I'm not sure where these values are coming from, but a review
>  of the Solaris source code should reveal the proper method.  Assuming
>  this can also me used for Linux, this would be the preferred method of
>  addressing the problem.
>
>  The second solution would be to switch from checking mtime to ctime.  The
>  use of ctime would pick up the name changes to the files and would solve
>  this problem as well.
>
>  I have brought this to the attention of the gThumb developers and they
>  suggested bringing this request to this list since the standard detect
>  algorithm is:
>
>         if (file.mtime != thumb.MTime) {
>             recreate_thumbnail ();
>         }
>
>  and the change must be built into the standard gnome UI library so that it
>  gets picked up by all gnome applications.  I don't think that making this
>  change in the UI library would break any existing code.  I hope you will
>  consider it for inclusion in an upcoming release.  The current behavior of
>  gThumb is driving me crazy.  :-)
>
>  Regards,
>
> --
>  Jeffery Small
>  _______________________________________________
>  desktop-devel-list mailing list
>  desktop-devel-list gnome org
>  http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>