GNOME Bugzilla – Bug 144256
Emblems of files/folders should be consistently preserved on copy/move/link
Last modified: 2010-08-02 12:58:13 UTC
Description of Problem: It is really annoying when moving files/folders around and sometimes the preservation of the emblems is inconsistent. Examples: * If I move a single file to another folder, the emblem is preserved as expected * If I move more than one file at once to a folder, but the target folder is not opened (in a nautilus window) the emblems are not preserved, otherwise they are * Moving a single folder to another one, not by drag and drop to another window, the emblem is lost, if it's moved by a drag and drop operation (window to window) the emblem is preserved. * When moving, not by window to window drag and drop, a folder with a emblem and with content files/folder with emblems, all emblems are preserved, except the emblem that belonged to the folder Sorry for my english, i hope you understand what i'm saying.
Also the emblems/notes aren't preserved when copying folders which might be a feature not bug however I think it would be more useful if the emblems were preserved even on copying.
retitling for clarity.
*** Bug 314183 has been marked as a duplicate of this bug. ***
*** Bug 159643 has been marked as a duplicate of this bug. ***
If a file or folder has multiple paths to it (e.g. a shared directory exists physically under /work/foo/bar and a there's a symlink to it in user's home, or "mount --bind" mount points in Linux), emblems added via one path don't show up under the other. This would happen for _any_ file/folder under that path, not just the symlinked base, since the metadata is referenced by the absolute path name. I guess this could be avoided if the metadata was stored inside the folder itself (like the .DS_Store files on the Mac) instead of under ~/.nautilus. That way emblems could also be file/folder specific, instead of being tied to the user account. IMO that would make sense; if more than one user can write to a directory, they are probably doing so for a common purpose. [This happens at least on Nautilus 2.10.0. I don't have possibility to test later versions ATM, sorry.]
Created attachment 51579 [details] [review] Proposed patch This patch will have to wait until 2.13 at least. It hopefully fixes those old eazel FIXMEs. I needed some time to find out that I'll have to manuall ref/unref the bonobo objects. Remarks - if either the source, or the destination metafile is not read and the copy operator is invoked, the patch takes care that both are read asyncronously and afterwards the metadata is copied - encapsulating multiple data types in a GList is very uncommon. Do you prefer a struct? I wonder which causes more memory fragmentation (multiple g_list_prepend vs. one malloc, containing four ptrs and g_list_prepend)
Oh, please note that this patch only seems to work if a file is copied rather than moved. Probably a NautilusFileOperations issue.
The problem rather seems to be that the move operation does copy and instant metadata removal from the source without waiting for the async copy. Maybe remove_file_metadata should wait for pending copies.
The patch was quiet broken, setting status to obsolete.
'Backgrounds and Emblems' have now been removed from nautilus master, see [1]. Closing this as OBSOLETE. [1] http://mail.gnome.org/archives/nautilus-list/2010-July/msg00023.html