GNOME Bugzilla – Bug 139935
Metadata are lost when moving/copying files to unvisited folders in Nautilus.
Last modified: 2013-04-24 13:24:10 UTC
Distribution: Debian testing/unstable Package: nautilus Severity: normal Version: GNOME2.6. unspecified Gnome-Distributor: GNOME.Org Synopsis: Metadata are lost when moving/copying files to unvisited folders in Nautilus. Bugzilla-Product: nautilus Bugzilla-Component: File and Folder Operations Bugzilla-Version: unspecified Description: Description of Problem: File metadata like "Icon", "Notes", and "Emblems" are lost when dragging or Cutting/Pasting files into unvisited folder icons in Nautilus. Steps to reproduce the problem: 1. Open a folder. 2. Add emblems and/or notes to a test file. 3. Find an unvisited folder icon, or create a new folder. Do not open it. This is the target folder icon. 3. Move or copy the file by dragging it to the target folder icon, or Cut/Copy the file from the source and use the Paste Into Folder option on the right-click menu of the target folder icon. 4. Open the target folder and inspect the test file's icon, emblems, and notes. Actual Results: The target test file is a tabula rasa (only name and contents preserved). When the process is repeated, however, everything works as expected. Expected Results: The move/copy operation should work even if the target folder has not been visited, or at the least a warning should alert the user about the possible loss. How often does this happen? Only with moving/copying to never-visited folders. Additional Information: Apparently the difference in behavior has to do with the .nautilus/metafiles/ entry being created only when the target folder is opened. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-04-13 11:55 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "nautilus". Setting to default milestone for this product, '---' The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@bugzilla.gnome.org. Previous reporter was eswartz@austin.rr.com. Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Thanks for your bug report. I can reproduce this issue on GNOME 2.8. It may be related to bug 43343.
OK, this seems to be 46526. But since the latter was closed (for no ovious reason), I'm leaving this one open.
See also http://bugs.debian.org/425109. This is reproducible with nautilus 2.18.
The original bug seems to have disappeared from 2.20.1... but a very similar one did raise. 1. Create a new directory 2. Create an empty file 3. Add emblems and a note to it (do NOT move it). 4. Move the directory to trash. Result: In trash all emblems and the note has disappeared (blanked out). Moreover, it seems that some elements have been lost in the hashtable: --- Hash table keys for warning below: --> �)ȵ Hash table keys for warning below: --> file:///home/fleury/Desktop/test --> file:///home/fleury/Desktop --> f --> file:///home/fleury/Desktop/test/tata (nautilus:13299): Eel-WARNING **: "nautilus-metafile.c: metafiles" hash table still has 5 elements at quit time (keys above) (nautilus:13299): Eel-WARNING **: "nautilus-directory.c: directories" hash table still has 5 elements at quit time This bug is extremely similar to the original one and deserve to be tracked down at once.
*** Bug 155893 has been marked as a duplicate of this bug. ***
Notes and emblems editing is not available anymore with recent versions of nautilus. Icon editing is still available. Emblems can still be set from the command line, so I used this command for testing this bug: > 'gvfs-set-attribute <filename> -t stringv metadata::emblems new favorite' I cannot reproduce this bug. I have followed the steps from comment 0 and from comment 4, but the custom icon and the emblems are preserved in both cases. I have tested this on Fedora 18, with nautilus 3.6. I have also tested git master via JHBuild. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME. *** Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.