After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 598145 - Brasero's failure with some file names
Brasero's failure with some file names
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
unspecified
Other Linux
: High critical
: 2.26
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-10-12 09:56 UTC by Tsu Jan
Modified: 2010-05-21 08:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tsu Jan 2009-10-12 09:56:13 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.
Comment 1 Tsu Jan 2009-12-10 12:00:09 UTC
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.
Comment 2 sdiconov 2009-12-27 12:31:41 UTC
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.
Comment 3 Tsu Jan 2010-03-21 03:20:03 UTC
This bug is still present in Brasero 2.29.92!
Comment 4 Tsu Jan 2010-04-10 23:24:04 UTC
Still present in 2.30.0, the last version I'll ever try. Good bye Brasero bug report!
Comment 5 Tsu Jan 2010-05-11 07:55:21 UTC
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.
Comment 6 Tsu Jan 2010-05-11 09:49:26 UTC
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.
Comment 7 Luis Medinas 2010-05-11 09:58:36 UTC
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.
Comment 8 Philippe Rouquier 2010-05-20 19:53:54 UTC
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.
Comment 9 Tsu Jan 2010-05-20 21:01:16 UTC
> ... 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.
Comment 10 Tsu Jan 2010-05-20 21:04:10 UTC
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.
Comment 11 Philippe Rouquier 2010-05-21 08:16:58 UTC
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.