GNOME Bugzilla – Bug 347744
Library transfer needs to determine 'unsafe' file characters
Last modified: 2008-09-20 07:21:06 UTC
When creating the filename for transferred files filepath_parse_pattern() uses sanitize_path() to remove problematic characters. Currently colons are not removed unless the CONF_LIBRARY_STRIP_CHARS gconf key is set to true, however colons are forbidden on fat32 paritions. We really need some way of figuring out what the "unsafe" characters are, as people often want the colons present if they are using a partition format that supports them, and other formats may have different "unsafe" characters.
One possibility would be to make the list of characters to remove user configurable. Another possibility would be to have "levels" of sanitisation so we try the lowest level first and if the OS rejects the filename we try a higher level of sanitisation, i.e. move possible problem characaters removed. Keep going up levels, i.e. removing more characters until the name is accepted.
Also remember this: in a ntfs filesystem, writing with ntfs3g you can use windows forbidden characters. here's some that I found: : < > In my opinion all these characters should be stripped or converted to "_" (as itunes does) This also happens when saving covers (they are saved as Artist - Album.jpg) and also when saving lyrics: remember that the configuration directory where lyrics and covers are stored might also be in a non-linux partition!
Hello, Can anyone tell me how to reproduce this bug? Thanks Aymeric
try to transfer a music file that has ":" in its filename to your fat32 portable mp3 player
Our problem is that I don't know how to transfer the file to fat32 portable mp3 player. Would you mind telling us how to do so step by step? Indeed, We are a french student group working on this bug trying to find a solution. Thank you very much Aymeric
step 1: add a file to rhythmbox library called file1:.mp3 step 2: plug a mp3 player in the usb port step 3: wait until it appears in rhythmbox, under the playlists in the menu at the left step 4: if it does not appear you should add the plugin Portable Players - MTP step 5: drag the music file from the library to the music player (in the menu) Is it enough for you? The key is that the music player should appear in rhythmbox. for sure ipod does this.
(In reply to comment #6) <snip> > Is it enough for you? The key is that the music player should appear in > rhythmbox. for sure ipod does this. media files are renamed before being put on the iPod, and it doesn't matter because the files are referenced in the iPod DB. It's harder for generic players, as they don't have such a database.
I'm afraid you are wrong... the filename is not changed, at least in rhythmbox version in ubuntu Gutsy
Some characters are replaced with more appropriate ones, but not all. The filename is changed as little as possible since that's better when you dnd a file from the ipod source to your gnome desktop. However, I was considering renaming the files and trying to improve dnd to assign a good-looking name to the file as part of the dnd operation
we were looking at the code source. We did note understand the exact role of the macro "CONF_LIBRARY_STRIP_CHARS" if (eel_gconf_get_boolean (CONF_LIBRARY_STRIP_CHARS)) { //Replacing problematic characters ... ... } We are wondering why we have to do the following test "if (eel_gconf_get_boolean (CONF_LIBRARY_STRIP_CHARS))"? We think that we can replace those characters systematicly(in all cases whaterver the value "CONF_LIBRARY_STRIP_CHARS" is).Is that possible? Otherwise why?
I think that this option strips forbidden characters always, when when it is possible to have them (for example ntfs and ext partitions). I think that what you should do might be to if (eel_gconf_get_boolean (CONF_LIBRARY_STRIP_CHARS)) { with if (eel_gconf_get_boolean (CONF_LIBRARY_STRIP_CHARS) || forbidden_character_supported(destination)) { of course you have to write the function forbidden_character_supported(destination) and to get the partition type somehow and pass it to the function
*** This bug has been marked as a duplicate of 374078 ***