Comment 2 for bug 23046

Please excuse the delay, I've had a hectic week at work.

You can use convmv to generate offending files. An example:

$ mkdir test
$ cd test
$ touch badfilename_ñ
$ convmv -f utf8 -t cp437 badfilename* --notest --nosmart
$ cd ..
$ mkisofs -R -J -o testimage.iso test
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 (badfilename_\uffff) encountered.
Possibly creating an invalid Joliet extension. Aborting.
$ ls -sh testimage.iso
64K testimage.iso

Since 64K are written, if you had used mkisofs to write to the CD/DVD on the fly
(say growisofs -Z /dev/hdc -R -J test), you would have wasted a CD/DVD. If I
recall correctly, this does not happen on other errors (for instance, when the
-joliet-long option is needed), because in that case mkisofs does not begin writing.

Maybe the test for the incorrectly encoded strings could be moved to the part
where the original Joliet name tree is created, so that no data is written to
the image before aborting. However, just replacing the offending characters with
'_' or something similar seems like the sanest idea.

I understand that this problem is not specific to Ubuntu (I have tested and
reproduced it also in a FC2 machine), but since the mkisofs version shipping
with Ubuntu is modified (and the cdrtools mantainer is rather strict in not
accepting bug reports for modified versions) I'm reporting it here.

I'm attaching a zipfile of the above test directory. You can unzip it and run
the above mkisofs line and it will abort.

Interestingly enough, non-utf8 characters of the isolatin-1 charset do not seem
to trigger the error (you may test it by replacing cp437 with isolatin1 in the
convmv line above); cp437 and cp850 do, though. However, this could be just a
coincidence because of the particular non-Unicode character chosen (Spanish ñ).

Let me know if you need any further assistance.

Best regards - CP