[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Joliet bug?
From: |
Burkhard Plaum |
Subject: |
Re: [Libcdio-devel] Joliet bug? |
Date: |
Fri, 05 May 2006 09:48:47 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1 |
Hi,
R. Bernstein wrote:
I just had a chance to look at this Joliet problem is in more detail.
First, I'd like to summarize to make sure I understand this correctly.
The problem observed is that the routine ucs2be_to_locale() in
iso9660_fs.c expects a stream of bytes that is UCS-BE16 (Universal
Character Set Big-Endian 16-bit), but is probably getting something
that is not that when it is called via
iso9660_ifs_get_preparer_id(),
iso9660_ifs_get_publisher_id(),
iso9660_ifs_get_volumeset_id(), or
iso9660_ifs_get_application_id().
However things are okay when ucs2be_to_locale() is called via
iso9660_ifs_get_system_id();
iso9660_ifs_get_volume_id();
Yes. You can easily reproduce it by hexdumping the string passed to
ucs2be_to_locale(). If you don't have a hexdump routine nearby, take this
(set last arg to 16 to get a linebreak each 16 bytes):
void bgav_hexdump(uint8_t * data, int len, int linebreak)
{
int i;
int bytes_written = 0;
int imax;
while(bytes_written < len)
{
imax = (bytes_written + linebreak > len) ? len - bytes_written : linebreak;
for(i = 0; i < imax; i++)
fprintf(stderr, "%02x ", data[bytes_written + i]);
for(i = imax; i < linebreak; i++)
fprintf(stderr, " ");
for(i = 0; i < imax; i++)
{
if(!(data[bytes_written + i] & 0x80) && (data[bytes_written + i] >= 32))
fprintf(stderr, "%c", data[bytes_written + i]);
else
fprintf(stderr, ".");
}
bytes_written += imax;
fprintf(stderr, "\n");
}
}
When ACSII characters (< 128) are printed in UCS-BE16, the first byte of each
character
must be 0x00.
If this is correct, at present I'm not sure yet whether the problem
has to do with the way the ISO 9660 was created or (more likely)
libcdio's interpretation. And to fix the libcdio's interpretation, I
guess I need to understand in which way libcdio messed up.
Ok, I tried just with one CD created by k3b. Maybe some CDs made by
other software can enlighten the situation.
For the ISO 9660 standard, I've been using the European draft ECMA 119
which is freely available at
http://www.ecma-international.org/publications/standards/Ecma-119.htm
However the relevant portion is probably this below (where BP refers to the
byte offset):
That's the iso9660 spec, right? I think the bug happens for Joliet only.
All calls to ucs2be_to_locale() are enclosed by
if(p_iso->i_joliet_level) { /* ... */ }
so I guess it shows up only when Joliet structures are present.
The observed behaviour is, that ucs2be_to_locale() fails in the mentioned cases
and the iso9660_*_get_*() functions return other strings (from plain iso9660?),
which are, indeed, correct.
Burkhard