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 42807 - support metadata removal for cases where we move/delete files
support metadata removal for cases where we move/delete files
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Metadata
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Darin Adler
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2000-09-05 14:27 UTC by pavel
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description pavel 2001-09-10 00:38:15 UTC
We need to enhance our metadata handling framework to support metadata removal.
This will be needed by the metadata copying task.



------- Additional Comments From darin@bentspoon.com 2000-10-12 13:01:09 ----

Seems like it's not required for PR2.



------- Additional Comments From darin@bentspoon.com 2000-11-01 14:44:38 ----

Bug 44359 describes a symptom of this.



------- Additional Comments From eli@eazel.com 2001-01-22 21:10:23 ----

Pavel or Darin ---

To verify this, may I just try one or two types of metadata? Are there special
classes of testing that should be checked beyond that?

Thanks!



------- Additional Comments From darin@bentspoon.com 2001-01-23 13:39:25 ----

It's fine to just try one or two. This was really an implementation task, so to verify we 
just need to see that the metadata is removed in the both the move and delete case 
(and maybe check that it isn't removed in the copy case).

Please note that the overall problem described by bug 45958 (and the three bugs 
dependent on it) can make this confusing, so the testing should be done with 
metadata that is written by the main Nautilus, not the notes sidebar panel or View as 
Music, or another other out-of-process metadata writer.



------- Additional Comments From eli@eazel.com 2001-01-26 21:54:53 ----

Appears fixed in Fri Jan 26 17:04:42 2001 build, but I'm not marking it verified
yet:

1. Added some emblems to 'fury.mp3' in /home/eli:
  <FILE NAME="fury.mp3">
    <KEYWORD NAME="certified"/>
    <KEYWORD NAME="cool"/>
{...etc...}
  </FILE>

2. Moved the file to the desktop:
 - the emblems disappear from /home/eli's metafile, and re-appear in the
desktop's.

3. Copied the file back to /home/eli
 - the emblems are retained in both /home/eli and the desktop's metafiles.

4. Dragged the file from the Desktop to the trash.
 - Emblems disappear from Desktop's metafile, nor do they reappear in
~/.nautilus/metafiles or /home/eli/.Trash. 

 Where are the emblems stored in this case? 

 [I'd like to see what happens to them when I then empty the trash.]




------- Additional Comments From darin@bentspoon.com 2001-01-29 09:04:15 ----

While the question of where the emblems are stored in the trash case is interesting, 
and could lead to discovering some new bugs, steps 1 and 2 alone are sufficient to 
verify that this bug was fixed and step 4 provides additional evidence that it's working.



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:38 -------
Bug blocks bug(s) 42199.

The original reporter (pavel@eazel.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.