Bug 113924

Summary: k3b should check filenames validity before burning on the fly
Product: [Applications] k3b Reporter: Francois Marier <francois>
Component: generalAssignee: Sebastian Trueg <trueg>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Francois Marier 2005-10-05 22:54:32 UTC 
Version:           0.12.4a (using KDE KDE 3.4.2)
Installed from:    Debian testing/unstable Packages

(This bug was reported by Guentcho Skordev <Guentcho.Skordev at stud.uni-karlsruhe.de> on the debian bug tracking system at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303572 )

Hello,

On ext2 filesystems (and maybe on some other filesytems) it is
possible to store the filenames in UTF-8 format. But it happens that
there are some invalid filenames. Possible reasons:
 1. some files saved in the past with other locale settings
 2. programs that store files without caring about the encoding
 
I have noticed that when I burn a Data CD 

 on-the-fly and with the Joliet extension, local filenames utf-8, 

invalid UTF-8 sequences in the filenames cause a
mkisofs error, but only after burning has been started, resulting in
an error message ("Error 1") and possibly a coaster.

I suggest testing for these problems before writing. (Doesn't mkisofs
make a dry run anyway? However, just mkisofs -print-size doesn't seem
to notice the problem.)
Comment 1 Andrea Fedeli 2005-11-24 07:43:44 UTC 
Here is what I got:

mkisofs
-----------------------
2088449
INFO: UTF-8 character encoding detected by locale settings.
 Assuming UTF-8 encoded filenames on source filesystem,
 use -input-charset to override.
...
Incorrectly encoded string (07_la_quiete_che_verrà.mp3) encountered.
Possibly creating an invalid Joliet extension. Aborting.

This happened *during* burning
Comment 2 Thiago Macieira 2005-12-11 16:28:13 UTC 

*** This bug has been marked as a duplicate of 117168 ***