GNOME Bugzilla – Bug 598145
Brasero's failure with some file names
Last modified: 2010-05-21 08:16:58 UTC
When there are some data files whose names include special characters, Brasero fails to burn the data or make an ISO image from them. Below is an example of such an error" ...................... BraseroGenisoimage stderr: /usr/bin/genisoimage: Error: '/media/sda9/Miscellaneous/Windows/Miaj Dokumentoj/Miaj Bildoj/Bildoj/Art Pictures/Miscellaneous/Edvard%20Munch,%20Vampire,%201893-4.jpg' and '/media/sda9/Miscellaneous/Windows/Miaj Dokumentoj/Miaj Bildoj/Bildoj/Art Pictures/Miscellaneous/Edvard%20Munch,%20Vampire,%201893-4.jpg' have the same Rock Ridge name 'Edvard%20Munch,%20Vampire,%201893-4.jpg'. BraseroGenisoimage stderr: Unable to sort directory /media/sda9/Miscellaneous/Windows/Miaj Dokumentoj/Miaj Bildoj/Bildoj/Art Pictures/Miscellaneous BraseroGenisoimage called brasero_job_error BraseroGenisoimage finished with an error BraseroGenisoimage asked to stop because of an error error = 16 message = "An image could not be created" BraseroGenisoimage stopping BraseroGenisoimage got killed ...................... Notice that there's only one file, namely, '/media/sda9/Miscellaneous/Windows/Miaj Dokumentoj/Miaj Bildoj/Bildoj/Art Pictures/Miscellaneous/Edvard%20Munch,%20Vampire,%201893-4.jpg'. Even when I put the folder 'Miscellaneous' on my desktop, the same error occurs, so it isn't related to deep folders or long file names. This behavior shows up with Brasero from v2.26.x to the latest one, i.e. v2.28.1. I'm in Debian squeeze/sid, kernel 2.6.30-2-686-bigmem and have no Windows partition. But the same error occurs in Ubuntu Gutsy, Hardy, Intrepid and Jaunty with the versions mentioned above.
This annoying bug is often reported and there are so many pages about "have the same Rock Ridge name" in Google but the dev team doesn't pay any attention to it :( I tried various file names and found that Brasero has problem with only those files whose names contain the form "%1a", where "1" and "a" can be replaced with any numeral and alphabet letter, respectively. Such files must be in a folder in the composition area to create a problem for Brasero. For example, the file "read%20this.txt", when it's in the folder "example" in the composition area, produces the above error and causes failure in burning. While the same file produces no error if it's directly in the composition area.
I confirm the existence of this bug. I have just filed another bug (605539) which seems to be similar, although it happened with Joiliet instead of RockRidge.
This bug is still present in Brasero 2.29.92!
Still present in 2.30.0, the last version I'll ever try. Good bye Brasero bug report!
The best reply to myself: This bug is perhaps related to genisoimage, not especially to Brasero. I changed the priority of libisofs-image in 'gconf-editor > apps > brasero > config > priority' from 0 to 2 and the problem was solved.
The real solution is to use Jörg Schilling's Cdrtools -- especially the original mkisofs instead of the buggy genisoimage. I tested it and it worked fine.
There isn't much Brasero can do... We'll leave to distributors and users to decide what's the best because brasero can use all backends.
I've got one question, the paths shows some "%" characters, do they appear in the normal file name (I mean in nautilus for example)? If you say that libisofs backend did the trick I'll probably raise its priority to 1 so it will be used instead of genisoimage.
> ... do they appear in the normal file name...? Yes, they do. The filename should contain some string similar to "%1a" and it should be in a folder. > If you say that libisofs backend did the trick ... In fact, the culprit was genisoimage. Both libisofs and the original mkisofs (belonging to Schilling's Cdrtools) are OK. And, Brasero is OK too ;) All in all, someone has to report a bug at genisoimage or tell the developers of Debian (and other main distros) to revert to the original Cdrtools.
BTW, before I replace genisoimage with the original mkisofs, I'd tested priority 1 for libisofs-image and it didn't work. However, priority 2 worked.
Yes, at one point I set genisoimage priority to 1 so libisofs had to have at least a priority of 2 to work. I changed all the priorities. Now in ascending order, priorities are: - genisoimage - mkisofs - libisofs As for why libisofs is the highest, it is because it should be promoted as much as possible (it is working well and has no "legal" issues) despite its lack of features mainly in the UDF area. Note a UDF file system is required, then mkisofs or genisoimage will be automatically picked so even the above order does not limit features. As a side note a Debian maintainer was thinking about adding libisofs by default to remove genisoimage. So it seems everyone has become aware of the wodim/genisoimage situation. I'm closing this bug but feel free to re-open it if you ran into it again.