genisoimage creates bad iso images if joliet is used - error: "Unexpected joliet directory length" appears
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Feisty Backports |
Invalid
|
Undecided
|
Unassigned | ||
cdrkit (Baltix) |
Fix Released
|
Medium
|
Unassigned | ||
cdrkit (Debian) |
Fix Released
|
Unknown
|
|||
cdrkit (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bug Description
Since Ubuntu 7.04 (Feisty, genisoimage version 1.1.6) CD burning causes a lots of problems for me and my friends - in lots of cases genisoimage creates bad iso images if joliet is used - error: "Unexpected joliet directory length" appears:
ubuntu@
I: -input-charset not specified, using utf-8 (detected in locale settings)
Using MANO_NUMERIS_
Using MANO_NUMERIS_
Using UBUNTU_
Using UBUNTU_
Using UBUNTU_
Using UBUNTU_
Using UBUNTU_
Using LINUX_WINDOWS_
Using LINUX_WINDOWS_
Size of boot image is 4 sectors -> No emulation
genisoimage: Unexpected joliet directory length 1112 expected: 1116 ''
1.40% done, estimate finish Thu Jan 31 03:34:32 2008
2.78% done, estimate finish Thu Jan 31 03:34:32 2008
[..]
This bug is not 100% reproducible, but it appears very often for me and others - it seems Joerg Schilling (original author of cdrecord software) is right - "the debian/ubuntu program (genisoimage) is a bad hack on a 2 year old version of mkisofs":
From: <email address hidden> (Joerg Schilling)
> To: <email address hidden>
> Subject: invalid Joliet table (was: genisoimage creates invalid iso images)
> Date: Sat, 14 Jul 2007 22:13:49 +0200
>
> do not expect to get any useful answer/help for your Debian bugreport. The projct is dead.
>
> BTW: I cannot see any problems with your data using a recent original software:
>
> http://
> ftp://ftp.
>
> The debian program is a bad hack on a 2 year old version of mkisofs.
When I downgraded to genisoimage 1.1.2-1 then this problem dissapears, like in other cases, described in debian bugs.
http://
Subject: genisoimage: Unexpected joliet directory length - this important bug is a duplicate of bug #429244
I also several times meet with the same problem in Ubuntu 7.04 and 7.10,
which uses the same version of genisoimage package - 1.1.6. The same error
message during genisoimage run:
"Unexpected joliet directory length" and the same problems, like
described in Debian bugs #429244 and #430558 :
From: Julian Andres Klode <email address hidden>
>To: <email address hidden>
>Subject: invalid Joliet table (was: genisoimage creates invalid iso images)
>Date: Sun, 08 Jul 2007 15:03:43 +0200
>
> It seems to me that the Joliet table is invalid.
>
> $ isoinfo -Jf -debug -i image.iso
> Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: ''
> /..
> /
> isoinfo: Short read on old image
>
> But "$ isoinfo -Rf -debug -i image.iso" works (Rock Ridge)
>
> $ isoinfo -J -d -debug -i image.iso
> CD-ROM is in ISO 9660 format
> System id: LINUX
> Volume id: Debian unstable i386
> [..]
> Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993
> E.YOUNGDALE (C) 1997-2006
> J.PEARSON/
> [..]
> Volume set size is: 1
> Volume set sequence number is: 1
> Logical block size is: 2048
> Volume size is: 376104
> Root directory extent: 57 size: 2048
> Path table size is: 11702
> L Path table start: 21
> L Path opt table start: 0
> M Path table start: 27
> M Path opt table start: 0
> Creation Date: 2007 07 07 20:51:50.00
> Modification Date: 2007 07 07 20:51:50.00
> Expiration Date: 0000 00 00 00:00:00.00
> Effective Date: 2007 07 07 20:51:50.00
> File structure version: 1
> El Torito VD version 1 found, boot catalog is in sector 1671
> Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: ''
> Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: ''
> Joliet with UCS level 3 found
> Rock Ridge signatures version 1 found
> Eltorito validation header:
> Hid 1
> Arch 0 (x86)
> ID ''
> Key 55 AA
> Eltorito defaultboot header:
> Bootid 88 (bootable)
> Boot media 0 (No Emulation Boot)
> Load segment 0
> Sys type 0
> Nsect 4
> Bootoff 688 1672
When I downgraded to version 1.1.2-1 then this problem dissapears, like in other cases, described in debian bugs.
Btw, it seems this important bug is a duplicate of bug #429244 :
From: Richard Kralovic <email address hidden> wrote:
>To: <email address hidden>
>Subject: genisoimage: Unexpected joliet directory length
>Date: Tue, 18 Sep 2007 14:04:09 +0200
>
> I can confirm this bug [..] (I was able to reproduce it only on one
> machine out of several almost identical ones).
>
> I was able to track down the bug to the diff between svn revisions
> 743 and 744 (The svn diff is attached). Indeed, after reverting this
> change, everything works.
I think it would be wise to stop creating bad and unmaintained forks of cdrecord and work together with Joerg Schilling (original author of cdrecord software) - it seems cdrecord is really free and really working, OSI approved software and there are no restrictions for patching and improving it - look here for more info:
Related branches
Changed in cdrkit: | |
status: | Unknown → New |
Changed in cdrkit: | |
status: | New → Fix Committed |
Changed in cdrkit: | |
status: | Fix Committed → Fix Released |
Changed in feisty-backports: | |
status: | New → Invalid |
There is a patch available at http:// bugs.debian. org/cgi- bin/bugreport. cgi?msg= 10;filename= cdrpatch; att=1;bug= 430558, but it is really annoying to patch unmaintained software.