volume label

[Kay Sievers]

On Wed, Mar 22, 2006 at 09:13:00AM +0100, Kay Sievers wrote:
> On Wed, Mar 22, 2006 at 08:40:59AM +0100, Matthias Bläsing wrote:
> > Am Mittwoch, den 22.03.2006, 07:35 +0100 schrieb Kay Sievers:
> > > On Wed, Mar 22, 2006 at 01:52:09AM +0100, Matthias Bläsing wrote:
> > > > Am Dienstag, den 21.03.2006, 15:53 +0100 schrieb Kay Sievers:
> > > > > On Mon, Mar 20, 2006 at 09:44:17PM +0100, Matthias Bläsing wrote:
> > > > > > I just burned two DVDs and was surprised by the interpretation by hal.
> > > > > > 
> > > > > > volname (as expected):
> > > > > > "KF/KJ Bilder 2 (2004+2005)"
> > > > > > 
> > > > > > but in hal I get:
> > > > > > volume.label = 'KF_KJ Bilder 2 ('
> > > > > 
> > > > > Please run (with the proper device node for you dvd drive):
> > > > >   /sbin/vol_id --export /dev/sr0
> > > > 
> > > > mblaesing at prometheus:~$ sudo /sbin/vol_id --export /dev/sr0
> > > > ID_FS_USAGE=filesystem
> > > > ID_FS_TYPE=iso9660
> > > > ID_FS_VERSION=Joliet Extension
> > > > ID_FS_UUID=
> > > > ID_FS_LABEL=KF_KJ Bilder 1 (
> > > > ID_FS_LABEL_SAFE=KF_KJ_Bilder_1__
> > > > mblaesing at prometheus:~$ sudo volname /dev/sr0
> > > > KF/KJ Bilder 1 (1958,1999-2003)
> > > 
> > > What does:
> > >   dd if=/dev/sr0 count=4096 bs=1 skip=32768 | hexdump -C
> > > print?
> > 
> > I attached the file and had a look at it and spotted what maybe the
> > reason. If you look at line 3 you see the "real" volume id, as specified
> > by me and reported by volname and in line 36 begins another entry, that
> > looks like the one recognised by hal. 
> 
> > 00000000  01 43 44 30 30 31 01 00  4c 49 4e 55 58 20 20 20  |.CD001..LINUX   |
> > 00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
> > 00000020  20 20 20 20 20 20 20 20  4b 46 2f 4b 4a 20 42 69  |        KF/KJ Bi|
>                                                                          ^
> > 00000030  6c 64 65 72 20 31 20 28  31 39 35 38 2c 31 39 39  |lder 1 (1958,199|
> > 00000040  39 2d 32 30 30 33 29 20  00 00 00 00 00 00 00 00  |9-2003) ........|
> 
> > 00000800  02 43 44 30 30 31 01 00  00 4c 00 49 00 4e 00 55  |.CD001...L.I.N.U|
> > 00000810  00 58 00 20 00 20 00 20  00 20 00 20 00 20 00 20  |.X. . . . . . . |
> > 00000820  00 20 00 20 00 20 00 20  00 4b 00 46 00 5f 00 4b  |. . . . .K.F._.K|
>                                                                             ^
> > 00000830  00 4a 00 20 00 42 00 69  00 6c 00 64 00 65 00 72  |.J. .B.i.l.d.e.r|
> > 00000840  00 20 00 31 00 20 00 28  00 00 00 00 00 00 00 00  |. .1. .(........|
> 
> Libvolume_id is correct (in the sense of expected behavior) in that
> case. You created a Joliet Extension ISO format which has a unicode
> label at the supplementary volume descriptor which is preferred over
> the "unknown/random encoding" label in the primary descriptor.
> 
> Unfortunately the unicode label is only half the length, cause only
> 16 16bit chars fit into the 32 char field. Therefore libvolume_id
> checks if both labels have exactly the same content and the primary
> one is used, if it contains the same string but is longer longer than
> the unicode one.
> 
> The program that created the ISO is so stupid to replace the '/' with
> a '_' and therefore the secondary descriptor (shorter but with sane encoding)
> is used. Please file a bug against the creator of the ISO image not to do
> this complete nonsense. Or don't use a slash in the label with that
> program. :)

Ok, I found it in cdrtools/mkisofs/name.c:
  if (c == '/')
          c = '_';

Seems you can't bypass this behaviour. I made an ISO CD and tried it on
Windows XP and it shows the Joliet Label without the '/' too, which makes
sense.

So just avoid '/' in the name, or try to get mkisofs fixed to translate
the name in the primary record too (which we use if it's identical but
longer) or don't translate the name in the second record.

Kay