I chased it some more; it seems that we -nearly- thumbnail, but we get to:

nautilus-directory-async.c (is_needy) which says 'no' because lacks_thumbnail says file->details->thumbnail_is_up_to_date [ie. it is up-to-date].

Of course, sadly it is not ;-)

This leads us to nautilus-file.c (update_info_internal) which seems to do:

	if (file->details->thumbnail != NULL &&
	    file->details->thumbnail_mtime != 0 &&
	    file->details->thumbnail_mtime != mtime) {
		file->details->thumbnail_is_up_to_date = FALSE;
		changed = TRUE;
	}

Unfortunately, at this point: file->details->thumbnail_mtime is 0:

	fprintf (stderr, "thumbnail is up to date %d %d %d %d mtimes [%d vs %d]\n",
		 file->details->thumbnail != NULL,
		 file->details->thumbnail_mtime != 0,
		 file->details->thumbnail_mtime != mtime,
		 file->details->thumbnail_is_up_to_date,
		 file->details->thumbnail_mtime, mtime);
yields:
thumbnail is up to date 1 0 1 1 mtimes [0 vs 1210253410]

So - we don't set thumbnail_is_up_to_date to FALSE.

This brings us back to: nautilus-directory-async.c (thumbnail_done) - the only place thumbnail_mtime is set.

Interestingly, as you instrument this method - it seems sometimes we get the right mtime, and sometimes we do not:

static void
thumbnail_done (NautilusDirectory *directory,
		NautilusFile *file,
		GdkPixbuf *pixbuf,
		gboolean tried_original)
...
		fprintf (stderr, "thumbnail done '%s'\n", thumb_mtime_str);
		if (thumb_mtime == 0 ||
		    thumb_mtime == file->details->mtime) {
			file->details->thumbnail = g_object_ref (pixbuf);
			file->details->thumbnail_mtime = thumb_mtime;
			fprintf (stderr, "set mtime on '%s' to %d\n",
				 file->details->name, thumb_mtime);

Yields (happily):

thumbnail done '1210253410'
set mtime on 'mydesktop.png' to 1210253410

initially, but then subsequently gives us:

thumbnail done '(null)'
set mtime on 'mydesktop.png' to 0

which is most curious - why would the GdkPixbuf *pixbuf sometimes have a valid tEXt::Thumb::MTime, and sometimes have none (?) - a mystery.

poking further - it seems that if I add nautilus-directory-async.c (thumbnail_start):

	if (g_getenv ("BAD_CHECK") &&
		file->details->thumbnail_size > 128) {
		fprintf (stderr, "size %d on '%s' set trying_original > 128\n",
			 file->details->thumbnail_size,
			 file->details->name
			);
		state->tried_original = TRUE;
		state->trying_original = TRUE;
		location = nautilus_file_get_location (file);
	} else {
		location = g_file_new_for_path (file->details->thumbnail_path);
	}

Then my thumbnails refresh as I would expect; of course - this is prolly totally wrong ;-) if BAD_CHECK is set I get:

size 144 on 'mydesktop.png' set trying_original > 128

Whence the magic 128 ? :-)

That's about all the time I can spend chasing it; Hope it helps.

Ah - one more critical thing (I guess based on the size) - I have my default IconView zoom set to 150% - which is an exacerbating factor here - turn that off, and re-thumbnailing works again: making me yet more suspicious of 128.

Created attachment 111196 [details] [review]
nautilus-bnc376669-always-update-thumbnail.patch

A patch that implements Michael's suggestion. Probably not the right solution, but something to test and criticize. I'd love to hear alexl's take on why the original code does what it does. Is it an optimization?

seems similar to bug #523883

Ok, so the issue here is that for large icon sizes we use the actual file as the pixbuf source instead of the thumbnail file. Of course, for theres files tEXt::Thumb::MTime won't be set. However, we should be able to just look at the current file mtime.

Created attachment 130462 [details] [review]
Fixes the issue

Let's mark this as accepted-commit_after_freeze so that we don't lose track of it after branching.

I got release-team acks, so commiting.