GNOME Bugzilla – Bug 608530
IPod coverart breakage, no graceful recovery after filling /tmp
Last modified: 2020-03-17 08:54:08 UTC
I had trouble getting all of the cover art to properly sync to my ipod and finally diagnosed this as a filled /tmp filesystem. I had a 500M /tmp, and banshee creates a tmp file over 1G when syncing. If it runs out of space, it just truncates and corrupts the artwork database and caries on with the sync. Expected behavior would be to detect the tmp file error, report it back up the the UI. and abort the sync. Work around: Expand /tmp. Blow away the DBs and content. Do full resync. This is a little hard to detect because the mono process holds open and writes to a deleted tmp file. This gives the symptom of /tmp slowly filling up, but du can't help you find the culprit. Once mono closes file handle, tmp space frees up again. lrwx------ 1 ferguson ferguson 64 2010-01-30 00:22 /proc/18605/fd/24 -> /tmp/tmp36cd1331.tmp (deleted) -ray
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.