I changed some lines in libnautilus-private/nautilus-metafile.c (trivial change)
which should make things work; I'm not sure and I'm sorry but I cannot test
because I have not installed nautilus from source, still it's a 5-liner patch,
so if anybody can test it; that would be nice.

Created attachment 46432 [details] [review]
Make nautilus copy thumbnails instead of regenerating when moving or copying files

Comment on attachment 46432 [details] [review]
Make nautilus copy thumbnails instead of regenerating when moving or copying files

Thanks for your patch. It copies the thumbnails fine, but
nautilus_update_thumbnail_renamed deletes the source thumbnail after copying.
Perhaps add a flag to the function and provide *_renamed and *_copied wrapper?

Created attachment 46439 [details] [review]
Make nautilus not removing the original thumbnail when moving :)

I have renamed nautilus_update_thumbnail_file_renamed() into
nautilus_update_thumbnail_file_copied_or_renamed() with an extra parameter
'gboolean copy' which copies the thumbnail when TRUE or moves the thumbnail
when set to FALSE.

The two wrapper functions nautilus_update_thumbnail_file_renamed() and
nautilus_update_thumbnail_file_copied() makes things a little more intuitive.

Is it also possible to make a symlinked folder use the same thumbnailes as the
original? Now, all those thumbnails have to be regenerated, and this can be
quite some work if there are a lot of files in that folder.

Michaël: Good point. The metadata for symlink'ed folders is kept around
seperately, it would be nice to have shared thumbnail data, though.

I will try to adapt my patch to that scenario also, please could somebody test
the last patch I submitted, I can't test it over here.

Comment on attachment 46439 [details] [review]
Make nautilus not removing the original thumbnail when moving :)

> 			
> 			unlink (old_thumbnail_path);
> 		}
>-		gnome_vfs_file_info_unref (file_info);
>+		
>+		if (!copy)
>+			gnome_vfs_file_info_unref (file_info);

That's not right. Unref doesn't delete something, but is part of the glib
memory management.
The unlink call is what's deleting the old file. Also, please don't use if
statements without braces (see the nautilus-coding-style document in the
repository).

>+/* copy or move thumbnail for a file */
>+void       nautilus_update_thumbnail_file_copied_or_renamed   (const char   	*old_file_uri,
>+						     	       const char   	*new_file_uri,
>+						     	       const gboolean	copy);

No need to export this signature, just export the wrappers.

However, it doesn't work as expected even when fixing the above. The reason is
that the mtime that is stored in the thumbnail doesn't fit the mtime of the
copied file. So the gnome-thumbnail factory won't recognize it as valid
thumbnail and thinks it needs to be updated. This is pretty hard to work
around, as nautilus/gnome-vfs has some strange mtime handling (it resets the
mtime of the copied file to the one of the original file after transfer).

It works if you do somthing like this:

	const char *mtime_file;

	if (copy) {
		mtime_file = old_file_uri;
	} else {
		mtime_file = new_file_uri;
	}

[...]
		if (gnome_vfs_get_file_info (mtime_file,
					     file_info,
					     GNOME_VFS_FILE_INFO_DEFAULT) ==
GNOME_VFS_OK) {

But I'm not sure why without digging through posix/gnome-vfs mtime handling
(you have to keep the rename case in mind too) - It might just work by chance.
Plus it won't work for large files, as the thumbnail is requested multiple
times during the transfer with varying mtimes. And I think that's basically
impossible to work around at the moment without some restructuring of the
thumbnailing code.

Note that the symlink issue (cf. comment 6) is filed as bug 45191.

*** Bug 76325 has been marked as a duplicate of this bug. ***

*** Bug 45191 has been marked as a duplicate of this bug. ***

Bug 45191 was actually a duplicate of this one, and contained a similar patch
(attachment 51947 [details] [review]).
Martin: I don't see why "the thumbnail is requested multiple times during the
transfer with varying mtimes.". Is this a GnomeVFS bug?

Martin?

Ping? :) My thumbnails dir has gotten up to 435M again- it would be really nice to get this into the next release since we've got at least a partial patch now.

Tangentially: does it make sense for this bug to also be 'delete thumbnails when deleting files'? Or is that a separate mechanism and hence a separate bug?

This one should have been fixed when we fixed bug 45191. Feel free to reopen it if it still doesn't work as desired.