genisoimage generates bad iso9660 directory records when excluding ".*"

[Huriaux Christophe]

genisoimage has a strange behavior when I try to exclude "hidden files" from the output ISO with the -m switch, it doesn't generate good "parent directory" records in subdirectories (see below) : the ISO image is thus non-compliant with the ISO9660 standard.

The following content with one directory at root and two files in this directory can reproduce this :
$ tree -a iso_content/
iso_content/
└── TestDir
    ├── file
    └── .hidden

1 directory, 2 files

I generate two ISO in order to compare the results, one with the hidden files excluded and the other with the complete tree (output of the second call is in attachment) :
$ mkisofs -o with_hidden.iso iso_content
$ mkisofs -m ".*" -o without_hidden.iso iso_content

The directory record concerning the directory "TestDir" in the full ISO is the following (sector 24) :
$ hexdump -s 49152 -n 2048 -C with_hidden.iso
0000c000 22 00 18 00 00 00 00 00 00 18 00 08 00 00 00 00 |"...............|
0000c010 08 00 6f 07 03 0f 07 0d 08 02 00 00 01 00 00 01 |..o.............|
0000c020 01 00 22 00 17 00 00 00 00 00 00 17 00 08 00 00 |..".............|
0000c030 00 00 08 00 6f 07 03 0f 06 0d 08 02 00 00 01 00 |....o...........|
0000c040 00 01 01 01 28 00 19 00 00 00 00 00 00 19 00 00 |....(...........|
0000c050 00 00 00 00 00 00 6f 07 03 0f 06 1a 08 00 00 00 |......o.........|
0000c060 01 00 00 01 07 46 49 4c 45 2e 3b 31 2c 00 19 00 |.....FILE.;1,...|
0000c070 00 00 00 00 00 19 00 00 00 00 00 00 00 00 6f 07 |..............o.|
0000c080 03 0f 07 0d 08 00 00 00 01 00 00 01 0a 5f 48 49 |............._HI|
0000c090 44 44 45 4e 2e 3b 31 00 00 00 00 00 00 00 00 00 |DDEN.;1.........|
0000c0a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000c800

The first record should describe the current directory record sector. The extent location at 0xC002 (0x00000018) designates the sector 24 which is OK.
The second record should describe the parent directory record sector. The extent location at 0xC024 (0x00000017) designates the sector 23, which is OK too.

If I look at the same location for the ISO with hidden files excluded :
$ hexdump -s 49152 -n 2048 -C without_hidden.iso
0000c000 22 00 18 00 00 00 00 00 00 18 00 08 00 00 00 00 |"...............|
0000c010 08 00 6f 07 03 0f 19 2b 08 02 00 00 01 00 00 01 |..o....+........|
0000c020 01 00 22 00 18 00 00 00 00 00 00 18 00 08 00 00 |..".............|
0000c030 00 00 08 00 6f 07 03 0f 19 2b 08 02 00 00 01 00 |....o....+......|
0000c040 00 01 01 01 28 00 19 00 00 00 00 00 00 19 00 00 |....(...........|
0000c050 00 00 00 00 00 00 6f 07 03 0f 06 1a 08 00 00 00 |......o.........|
0000c060 01 00 00 01 07 46 49 4c 45 2e 3b 31 00 00 00 00 |.....FILE.;1....|
0000c070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000c800

The first and second records (at 0xC002 and 0xC024) both points to the *current directory*.

 The ISO9660/ECMA-119 standards explicitly says that the second record should describe the parent record in all directories except the root directory, this behavior is thus undesirable and could breaks ISO9660 implementations which only rely on the records and not on the path table to traverse the directories.

-------------------------------------------
Ubuntu 11.04 Natty Narwhal
genisoimage 9:1.1.11-1ubuntu2 .

[Schily (schilling-fokus)]

genisoimage is an unmaintained fork from a 7 year old mkisofs.

5 years ago, _many_ bugs have been fixed in the original mkisofs.
Did you try a recent original cdrtools:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

P.S. do not expect a fix in genisoimage.....

[Huriaux Christophe (c-huriaux)]

Effectively I don't have this "bug" with the mkisofs bundled with cdrecord 3.01a5 . I don't want to be picky I can't understand why this fork is left unmaintained whereas a lot of things has been fixed in mkisofs. However, it won't ruin my day, thanks for your answer.

[Schily (schilling-fokus)]

The fork has been created together with a social attack against the original project.

You may like to ask why Ubuntu supports the social attack instead of supporting the original software.