GNOME Bugzilla – Bug 346434
iPod song deletion should physically remove the files instead of only moving them to trash
Last modified: 2008-04-27 15:25:30 UTC
Please describe the problem: Transfering songs to the iPod works fine, however when deleting the songs the error occurs. With the ipod selected, selecting a song and "Moving to Trash", removes the song from the iTunesDB. Looking at the iPod or the songlist in rb, everything looks ok, however rb doesn't delete the song (possibly the art either). This leaves the iPod full of orphaned songs. the only way to fix it is to re-format the iPod. Steps to reproduce: 1. Use df -h to check the HD space on iPod 2. Select all songs in the iPod 3. Delete the songs "Move to Trash" 4. Check HD space again (still the same) Actual results: I end up with an iPod with no playable songs, and a full HD. Expected results: The songlist entry as well as the song should be gone (thus freeing up HD space) Does this happen every time? Yes Other information: Rhythmbox CVS (1 July, 2006 + patch from #346378), iPod Nano 2GB
Does rhythmbox -d display messages like "Deleting XXXX failed: XXXX"? The iPod source code does: remove_track_from_db (track); g_hash_table_remove (priv->entry_map, entry); rhythmdb_entry_move_to_trash (db, entry); rhythmdb_commit (db); ie, it removes the songs from the iPod database, and then asks rhythmbox to move the physical file to trash, but maybe there's a bug with that.
Moving to trash may fail if there is no trash directory on the ipod (.Trash-username or .Trash-uid)
Here's the output from `rhythmbox -d` right after trying to delete an album. Failed to write a byte at 16777216: No space left on device Couldn't create /media/sde2/iPod_Control/Artwork/ArtworkDB (09:52:08) [0x625770] [paned_size_allocate_cb] rb-browser-source.c:720: paned size allocate (09:52:09) [0x625770] [rb_shell_clipboard_sync] rb-shell-clipboard.c:489: syncing clipboard (09:52:09) [0x625770] [rb_shell_clipboard_entryview_changed_cb] rb-shell-clipboard.c:706: entryview changed (09:52:09) [0x625770] [rb_shell_clipboard_sync] rb-shell-clipboard.c:489: syncing clipboard IMHO, there shouldn't be any trash on the ipod, just physically delete the media. Also just checked df -h closer, the iPod has LESS space on it after deleting the songs.
(In reply to comment #3) > Also just checked df -h closer, the iPod has LESS space on it after deleting > the songs. > Then maybe the files went to the trash and you need to empty it? (just a suggestion, I haven't checked what happens)
Add to iPod tracker.
From comment 1, > The iPod source code does: > remove_track_from_db (track); > g_hash_table_remove (priv->entry_map, entry); > rhythmdb_entry_move_to_trash (db, entry); > rhythmdb_commit (db); Could this be changed so that instead of rhythmdb_entry_move_to_trash it actually does "really delete entry not just move to trash" instead?
Retitling bug for more clarity (feel free to retitle it more clearly if my English sucks ;)
And updating priority/severity, Mike, please tell us if emptying the trash didn't solve your free space issue (in which case this would be a real bug instead of some behaviour that can be improved)
As of a few CVS Revisions ago, it seems to be deleting the song as well as the iTunesDB entry. once in a while it doesnt delete, I'll try to see if there's a pattern but I would feel comfortable marking this bug as closed.
Using 0.9.7, files are not deleted from the iPod. Debug output when deleting a track: (18:25:46) [0x8152000] [rb_shell_clipboard_cmd_move_to_trash] rb-shell-clipboard.c:683: movetotrash (18:25:46) [0x8152000] [rhythmdb_query_model_entry_changed_cb] rhythmdb-query-model.c:905: emitting hidden-removal notification for file:///media/IPOD/iPod_Control/Music/F19/05-moku.rei.kyousei.mp3 (18:25:46) [0x8152000] [rhythmdb_property_model_delete_prop] rhythmdb-property-model.c:629: deleting "Anime": refcount: 1 (18:25:46) [0x8152000] [rhythmdb_property_model_delete_prop] rhythmdb-property-model.c:629: deleting "Kunihiko Ryo": refcount: 1 (18:25:46) [0x8152000] [rhythmdb_property_model_delete_prop] rhythmdb-property-model.c:629: deleting "12 kokuki Yomogi Yama Enkei - Kokyu Memories": refcount: 1 (18:25:46) [0x8152000] [rb_entry_view_row_deleted_cb] rb-entry-view.c:1715: row deleted (18:25:46) [0x8152000] [rb_shell_clipboard_entries_changed_cb] rb-shell-clipboard.c:779: entryview changed (18:25:46) [0x8152000] [paned_size_allocate_cb] rb-browser-source.c:719: paned size allocate (18:25:47) [0x8152000] [rb_shell_clipboard_sync] rb-shell-clipboard.c:528: syncing clipboard (18:25:47) [0x8152000] [rb_shell_clipboard_entryview_changed_cb] rb-shell-clipboard.c:771: entryview changed (18:25:47) [0x8152000] [rb_statusbar_source_status_changed_cb] rb-statusbar.c:502: source status changed (18:25:47) [0x8152000] [rb_shell_clipboard_sync] rb-shell-clipboard.c:528: syncing clipboard After which /media/IPOD/iPod_Control/Music/F19/05-moku.rei.kyousei.mp3 still exists.
Can you still reproduce with rhythmbox 0.9.8?
Created attachment 85417 [details] [review] Fix the way rhythmbox moves files to the trash If a trash directory does not already exist on the removable device, it was not being created and the file was not being deleted. Now, if a trash device is not found, it is created and the file moved to it normally. Separately, should rhythmbox unlink a file if it is unable to move it to trash?
That's a bug fix in my trash code :) Looks good.
Thanks for investigating that issue! (In reply to comment #12) > > Separately, should rhythmbox unlink a file if it is unable to move it to trash? > I think in such cases Nautilus displays a warning saying "Cannot move file to trash, is it okay to physically remove it from the disk?", maybe we should do the same?
Created attachment 85438 [details] [review] Create trash, and if that fails, prompt to unlink Prompting the user seems like a reasonable course of action. Patched updated with dialog inspired by nautilus/rb_error_dialog.
What needs to be done to get this patch into svn?
What needs to be done is to get someone to look at it ;) Hadess, can you have a look ?
The patch makes the database pop up a dialog, which isn't good. However, I don't think there is any reason reason for those functions to be in RhythmDB itself (aside from a "there was no-where else obvious to put it"). Moving this, and other random utility functions, somewhere else might be a good idea - so we can make RhythmDB just a base class for database implementations.
If the solution is to move songs to the trash, I think that something is to be added in the ipod support: a way to recover the deleted songs or to definitely erase them it could be in the left under the ipod entry in devices, like a playlist Devices v ------ My ipod -> deleted songs Without this option, in my opinion, moving the songs to trash has no sense, and it whould be better to erase them directly. What do you think?
I think that the item should just be deleted without even attempting to move it to a trash. btw This is the way that iTunes does it.
I would second William on this. iPod is not considered as a primary storage of the media but as partial "mirror" of "backup" of the collection on PC. So if person erroneously deletes something on iPod, he/she can readd the stuff from PC. Please please delete it physically, no need in excessive GUI actions (to cleanup the iPod garbage).
I second this too. I just added that comment because I thought that moving to trash would not be substituted with normal delete. There is definitely no need of an iPod trash at all
Running 0.11.1 with a gen 5.5 30G iPod FAT formatted, I have no trash visible on the device. "Moving to Trash" removes the entry from the itunes db, but the space is never freed up. Can we please get *something* in here to actually delete the files? I agree completely with William and Sergey Udaltsov, there is no reason to have separate trash and delete actions. A method to delete orphaned files would also be nice. Otherwise, even with deletion functionality added, there would be no way of cleaning out orphaned files, short of reformatting/recopying everything (and re-transcoding -- in my case all of my files ripped from my CD collection are flac).
For now, gnupod should save you. Run the following command to view orphaned files: # gnupod_check After that, you can run: # gnupod_check --fixit that will clear the files. Honestly, this bug should have been taken care of a year ago. Its the one reason I don't use Rhythmbox.
Created attachment 97151 [details] [review] rb-delete-ipod-tracks.patch Would that do? I'm not sure we'd want to a "move to trash" for iPods anyway.
This patch seems to fix the issue for me. I did a build of rhythmbox-0.11.2 (I had to fudge the patch a bit to make it apply to Fedora F-8 CVS). I can confirm that after asking the files get moved to trash via rhythmbox the files are removed from the device (a 1G shuffle in my case) and the space is recovered. I would consider this patch a fix.
Seems sane to me. It's probably worth making this consistent between all the removable-media support plugins.
(In reply to comment #27) > Seems sane to me. It's probably worth making this consistent between all the > removable-media support plugins. Actually, that's only ever a problem for plugins that use a database. If they don't use a database, the file should stay around so it can be restored (and the action would be fully reverted). Other plugins should have an option about emptying the trash before umounting.
Hi there, I encounter the same bug and I you like to apply the patch described above to solve it. Unfotunately, as a newbie, i have no idea how to apply it. I would be glad if you could explain how to run this patch or redirect me to a documentation page. Thanks in advance,
Hi there, I encounter the same bug and I would like to apply the patch described above to solve it. Unfortunately, as a newbie, i have no idea how to apply it. I would be glad if you could explain how to run this patch or redirect me to a documentation page. Thanks in advance,
Please change the severity of this bug from "enhancement". The most current version of trunk is still creating orphan files. Is there any chance that the unlink patch will get merged into trunk soon?
The patch looks fine to me, feel free to commit.
2007-11-27 Bastien Nocera <hadess@hadess.net> * plugins/ipod/rb-ipod-source.c: (impl_move_to_trash), (impl_build_dest_uri), (request_artwork): Don't put iPod tracks in the wastebasket when deleting them, they lost their database entry so they're unrecoverable (Closes: #346434)
*** Bug 520044 has been marked as a duplicate of this bug. ***
# df -h /dev/sdb1 7.5G 3.5G 4.0G 48% /media/IPOD # gnupod_INIT -m /media/IPOD Creating directory structure on /media/IPOD etc, etc. # gnupod_check --fixit -m /media/IPOD gnupod_check.pl Version 0.98.3 (C) Adrian Ulrich Pass 1: Checking Files in the GNUtunesDB.xml... Pass 2: Checking Files on the iPod... ..finished Total Playtime : 0 h Space used : 0.00 GB iPod files : GNUpod files : -> Nothing fixed, no need to rewrite the GNUtunesDB.xml # df -h /dev/sdb1 7.5G 3.5G 4.0G 48% /media/IPOD A du -c on /media/iPod does not add up to the 3.5gigs it claims is being used. I have repeatedly reset settings to no avail. Ubuntu Hardy 8.04 Rhythmbox 0.11.5
Further down the rabbit hole... I tried rm -rF and still couldn't recover the space, so googling I ran across this command and it returned some interesting results. It seems theres a boot sector backup reporting incorrect file system space. # dosfsck /dev/sdb1 -rV dosfsck 2.11, 12 Mar 2005, FAT32, LFN There are differences between boot sector and its backup. Differences: (offset:original/backup) 73:44/4f, 74:4f/44 1) Copy original to backup 2) Copy backup to original 3) No action ? 1 Starting check/repair pass. Reclaimed 229159 unused clusters (3754541056 bytes). Free cluster summary wrong (255927 vs. really 485086) 1) Correct 2) Don't correct ? 1 Starting verification pass. Perform changes ? (y/n) y /dev/sdb1: 30 files, 13/485099 clusters # df -h /dev/sdb1 7.5G 208K 7.5G 1% /media/IPOD