After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 45191 - Thumbnails regenerated upon 'Create Link'
Thumbnails regenerated upon 'Create Link'
Status: RESOLVED DUPLICATE of bug 304184
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.12.x
Other All
: Normal trivial
: 2.12.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2000-12-15 01:31 UTC by eli
Modified: 2005-09-19 13:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Proposed patch (5.34 KB, patch)
2005-09-08 08:15 UTC, Christian Neumair
committed Details | Review

Description eli 2001-09-10 00:48:16 UTC
If you context-click on an image file and select "Create Link" from the context
menu, Nautilus will create a new thumbnail for the link, rather than using the
existing icon.

* REPRODUCIBLE: Always

* STEPS TO REPRODUCE:

1. Place an image file (GIF, JPEG or PNG) into a folder. (you'll have an easier
time later if the folder is otherwise empty or sparsely populated.)

2. Context-click on the file, and select "Create Link"

* ACTUAL RESULTS: 

 Nautilus creates the linked file. 

However, for its first few seconds of existence, it has the "Image Loading"
hourglass icon.

Pavel suggests that it may be a bug that we're not re-using the existing
thumbnail icon. (as we do for file renaming.)



------- Additional Comments From snickell@stanford.edu 2001-07-23 00:33:06 ----

Taking bugs previously assigned to Pavel, assigning them to myself. Will parse
them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:48 -------
Comment 1 Luis Villa 2002-11-06 20:28:03 UTC
Still happens with the new thumbnailing code.
Comment 2 Sebastien Bacher 2003-12-06 23:12:30 UTC
Still here with Nautilus 2.4.1 => GNOMEVER2.4
Comment 3 Sebastien Bacher 2004-10-19 18:44:25 UTC
still here with 2.8.1 ...
Comment 4 mike morrison 2004-12-05 01:58:15 UTC
The following also happens to me (on 2.8.2):

1. Open a directory in nautilus that contains images or videos (~/images/ as an
example). Thumbnails will either already be there, or will get generated.
2. Now create a link to this directory in another location. (ln -s ~/images
~/images_link)
3. Open the link in nautilus (~/images_link/). Nautilus will create new
thumbnails for all items in this directory!

I think it should be using the thumbnails that already exist for these items. Is
this the same issue, or should a new bug be created?
Comment 5 Christian Neumair 2005-05-21 15:48:44 UTC
Mike: Yes it is the same issue.

From bug 304184, comment 6:
The metadata for symlink'ed folders is kept around
seperately, it would be nice to have shared thumbnail data, though.
Comment 6 Michaël Arnauts 2005-05-21 15:52:57 UTC
Isn't it possible to lookup the symlink and use the original filename for the
thumbnail instead?
That would only have to add a few lines given that such a
"get-original-filename"-function already exists... if that doesn't exists, it
just a matter of going trough the path and see if a parent folder is a symlink...
Comment 7 Christian Neumair 2005-09-08 08:15:21 UTC
Created attachment 51947 [details] [review]
Proposed patch

The attached patch takes care that when copying metadata (upon
moving/copying/linking), the thumbnail is copied as well. I've also submitted
this patch to the nautilus mailing list [1] for review.

[1] http://mail.gnome.org/archives/nautilus-list/2005-September/msg00088.html
Comment 8 Christian Neumair 2005-09-08 08:17:27 UTC
Michael: For now, I've made a straightforward solution - copying the metadata
when copying/moving/linking, that is. I think that because links have separate
metadata from the original files anyway, it's a good idea to just copy the
thumbs over.
Comment 9 Christian Neumair 2005-09-10 20:38:19 UTC
Marking th is one as duplicate of bug 304184. The latter has a similar patch and
additional information.

*** This bug has been marked as a duplicate of 304184 ***
Comment 10 Christian Neumair 2005-09-19 13:53:43 UTC
Committed attachment 51947 [details] [review].