GNOME Bugzilla – Bug 399278
USB Mass Storage doesn't escape/strip special characters in filenames
Last modified: 2009-12-30 00:15:00 UTC
Please describe the problem: I have a mass storage DAP (Cowon X5), a library with 10324 songs and a playlist with 3103 songs. After connecting my DAP, I select all files in my playlist and drop them onto my DAP player. Songs are transfered, but only 3078 songs made it onto the device. I have repeated many times, no errors are logged to console. With the large number of files I'm not sure if the files are missing, or it's not reading some of them correctly from the device....If I had ability to export the playlist to an m3u I could compare that with the files on the device..unsure how else to check this out. Steps to reproduce: 1. Transfer files to DAP 2. See that they're not all there.. 3. Actual results: Expected results: All files from playlist would be transfered. Does this happen every time? Yes Other information:
One reason files wouldn't transfer is if you have duplicates (eg exact same Artist/Album/Track/TrackNum). Other than that, I'm not sure. I think a boo script could come in handy here to compare what's on your DAP to what's in the playlist. I'll try to write one soon if nobody else does first.
Thanks that would help. The DAP also reports 3078 songs. Also my music folder on the desktop is already stored on a FAT partition, so it shouldn't be anything with invalid charecters in the filenames..
Hmm, there might be, actually, b/c the mass storage support creates its own file names (from the track's metadata), mostly to comply w/ certain DAPs that require a particular folder depth. So if any of your tracks' names/artist/albums contains invalid FAT filename characters, then that might be the issue.
I think this is what happened. (I'm having some other problems with 11.5 now so I'm not able to sync everything up quite yet). I found quite a number of files that had ? and ! in the tags but not in the current filenames. Can we change this to a usability request to have banshee strip invalid chars during the export or do I need to file a separate one for that?
No, it's good as is Jason. Thanks.
So I looked at the code tonight, and I am actually escaping the pieces, using Banshee's existing escaping code. It doesn't look like it escapes !'s, but I just tested copying a song w/ a ! in its title and it worked fine on a FAT16 formatted thumbdrive. The escaping code doesn't escape &'s, so I just had a song that failed to transfer b/c of that. If that's not the character that's causing the problem for you, let me know.
BTW, I just committed a change to SVN so that errors thrown while transferring will be logged if you run bashee --debug
I'm not sure what's going wrong. I grabbed the svn code and ran with debug dumping the output to a logfile. I had 3117 songs in my playlist, and after transfer, 3098 on the device. even copied over again, which nothing actually was moved but the count stays the same. Log file just shows a 'have path' for every song, no errors..There are 3110 'have path' entries in my log file. which doesn't match either.. I did edit a lot of tags, I got rid of !, and ? and everything else I could think of, but not all the &s because I had a lot. There are still 84 tracks in my playlist with & in them, so I don't believe that character is the issue. Curiously there are 19 songs exactly with & in the artist name (which is the difference from 3117-to-3098), but those songs are in the logs and on the device - no dice there. I filtered the library on every special character on my keyboard, every one I found with one is making it onto the device. I guess I need to start breaking this down into smaller chunks and trying to figure out which tracks aren't making it..
This bug may be the same (or at least related) to one I just filed: http://bugzilla.gnome.org/show_bug.cgi?id=413961
Craig, thanks for your report, I'm going to close it as a dupe of this one. Here is Craig's report: Opened by Craig (reporter, points: 0) 2007-03-02 19:00 UTC [reply] Say you have an item in your library with this metadata: Album: "This American Life, " Title: "307 - Episode" And you set Banshee to save in the Album/Title structure. The path to be written to the DAP will be: "This American Life, /307- Episode.mp3" However, this is not a legal VFAT path - directory names cannot end in a space. Another example of this happening is when some component of the metadata contains dots, such as .. or ... The path will contain those dots, which are once again not legal VFAT names. I assume there are other characters that can cause these errors as well, but I haven't run into them yet (I bet star, pipe, colon, slash, backslash, less than, and greater than do similar things).
*** Bug 413961 has been marked as a duplicate of this bug. ***
Gabriel, is this bug still valid? If not, please close as OBSOLETE.
I'm having this issue still, (in the release of 1.4 that I got from https://edge.launchpad.net/~banshee-team/+archive) The problem I have is with :'s and attempting to put them on my usb thumb drive through the Mass Storage Plugin. I can try to run with the --debug flag later today if that will help.
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
Colons are now stripped. We should be compatible with FAT32, NTFS, HFS, and ext3 filesystems, and probably most others.