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 586649 - Leaves .Trash-1000 directories all over disks & iPod
Leaves .Trash-1000 directories all over disks & iPod
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: general
0.12.x
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-22 15:01 UTC by jgoerzen
Modified: 2009-12-28 09:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rhythmbox -D ipod output (57.20 KB, text/plain)
2009-06-23 00:35 UTC, jgoerzen
Details

Description jgoerzen 2009-06-22 15:01:29 UTC
Please describe the problem:
I have rhythmbox 0.12.1 running under KDE 4, though I have observed this without KDE as well.

Rhythmbox has no "delete tracks" option; rather, it has a "move to trash" option.  The problem is that it doesn't move to trash.  Rather, it creates a .Trash-1000 directory in whatever filesystem the track was on and moves it there.  KDE doesn't empty this directory.  As a result, deleting tracks actually causes MORE disk space to be used because of the metadata also added to .Trash-1000.

Worse, it even does this on the iPod.  It does properly remove metadata from the iTunes DB, but it leaves the files in .Trash-1000 at the top-level of the iPod.  I couldn't figure out why my iPod kept getting more full the more I deleted until I finally noticed that.  It is *especially* wrong to be doing this sort of thing on an iPod.

rhythmbox should not offer to move things to trash when there is no guarantee that something on the system will empty the trash it creates; it should offer a pure delete option.  Furthermore, on the iPod, it should never create a .Trash-1000 directory at all.

I surmise that the 1000 comes from my uid.

Steps to reproduce:
1. Move tracks to trash
2. Observe a .Trash-1000 directory on whatever filesystem it was on
3. 


Actual results:
Hidden .Trash-1000 directory shows up instead of tracks being deleted or moved to trash

Expected results:
Tracks being deleted or moved to trash

Does this happen every time?
yes

Other information:
Comment 1 Jonathan Matthew 2009-06-23 00:02:22 UTC
We use gio's g_file_trash function to perform the 'move to trash' operation, and it implements the xdg trash spec.  If KDE doesn't support this, that's not really our problem.

I'm puzzled that it'd create a trash directory on an ipod, since the 'move to trash' implementation for the ipod plugin (as opposed to the default implementation) simply deletes the file.  Are you sure you have the ipod plugin enabled (edit->plugins, look for 'portable players - ipod')?  What output do you get from 'rhythmbox -D ipod' with the ipod plugged in?

Whether we should actually do 'move to trash' for media devices is another matter (see bug 584704 for the latest, there are probably others).
Comment 2 jgoerzen 2009-06-23 00:34:24 UTC
Hi Jonathan,

Thanks for the follow up.  Let me address the iPod questions first, and then the larger question.

The iPod plugin most certainly is activated, working, and active.  (The MTP plugin is even disabled.)  If I right-click on the iPod device and hit properties, under the Advanced tab, it will list the model number (MA147), serial number, and atabase version even.

I will attach the output of rhythmbox -D ipod as soon as I finish these comments.  I think that, regardless of the larger question, on an iPod, there should never be a .Trash-1000 created at all.

As to the more general problem: On some machines, I don't run a desktop environment at all.  On my Eee, for instance, I just run xmonad -- a tiling window manager.  No Gnome, KDE, or XFCE and it suits me just fine.  There is nothing on that machine that could understand what a Trash is, let alone any xdg trash spec.  On such a device, rhythmbox litters my disk with its .Trash-1000 directories.  It's a perfectly valid way to run X software, and in fact was the normal way to do so until fairly recently.

A similar problem may exist for removable media: if rhythmbox creates a .Trash-1000 directory and you remove it, then mount it on Windows, MacOS X, or even as a user with a different UID on your own box, the trash won't be emptiable in the usual way.

I would like to see one (or more) of these options:

1) An option to delete tracks outright wherever there is an option to move them to the trash

2) A preference setting that says that "move to trash" really means "delete immediately"

3) An interally-managed trashcan that moves tracks to ~/.rhythmbox/trash or some such

4) A warning at first start (or first mount of iPod) about the trash behavior.  The iPod thing in particular had me really quite puzzled for awhile.

Thanks for listening.

-- John
Comment 3 jgoerzen 2009-06-23 00:35:50 UTC
Created attachment 137220 [details]
rhythmbox -D ipod output
Comment 4 Jonathan Matthew 2009-06-23 09:30:50 UTC
If we actually are creating trash directories on ipods, then that's a bug, not something we should add warnings about.  The current intent of the code is that files on ipods will be deleted rather than trashed, and this will probably be the case for all media player devices in the future.

In my limited testing I haven't seen a trash directory being created on the ipod filesystem.  I can't see an execution path that would result in this happening either.  You could try running rhythmbox under gdb, setting a breakpoint on g_file_trash, and seeing if/where it's being called from.

If rhythmbox truly is littering your disk with .Trash-$uid directories, rather than creating one at the root of a volume for files trashed on that volume, that's a bug in the trash spec or in gio's implementation of it.

You don't need a desktop environment to make use of trash: 
http://code.google.com/p/trash-cli/

Anyway, for files on the host filesystem, I think it'd be reasonable to provide the same preferences as nautilus.
Comment 5 jgoerzen 2009-06-23 13:49:59 UTC
Done.  Here's the backtrace:

  • #0 g_file_trash
    from /usr/lib/libgio-2.0.so.0
  • #1 rhythmdb_entry_move_to_trash
    at rhythmdb.c line 3732
  • #2 default_move_to_trash
    at rb-source.c line 1198
  • #3 rb_source_move_to_trash
    at rb-source.c line 1220
  • #4 rb_shell_clipboard_cmd_move_to_trash
  • #5 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #6 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #7 ??
    from /usr/lib/libgobject-2.0.so.0
  • #8 ??
  • #9 ??

Comment 6 Jonathan Matthew 2009-06-24 13:12:18 UTC
Of course, I forgot to check if ipod playlists used the same move-to-trash implementation as the main ipod source; and of course they don't.  So, I've fixed that (commit 3b13bc39f524f15023dff660090f660c8fa0b7d3).
Comment 7 Jonathan Matthew 2009-12-28 09:53:20 UTC
All the other issues mentioned here are covered by other bugs (bug 448137, bug 584704, mostly) so I'm closing this one.