$ mkdir empty

$ genisoimage -r empty/ > 1.iso
I: -input-charset not specified, using iso-8859-2 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 169
Total directory bytes: 238
Path table size(bytes): 10
Max brk space used 0
175 extents written (0 MB)

$ genisoimage -M 1.iso -C 0,0 -r empty/ > 2.iso
I: -input-charset not specified, using iso-8859-2 (detected in locale settings)
Rock Ridge signatures found
Using 
000;1 for  /.. (..)
genisoimage: Error: '/..' and 'empty/..' have the same Rock Ridge name '..'.
Unable to sort directory

This bug has been introduced by Debian.

Upgrade to a recent original version from:

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

and it will go away.

Jörg

The underlying problem appears to be an earlier bug in genisoimage or
its cdrtools predecessor (I didn't track it down), such that .. entries
get created without the ISO_DIRECTORY flag attached. This torpedoes
image merging with such images specified in -M because we end up with
two .. entries in the directory, one a directory, one a file.

This bug no longer appears to be present --- images created by this
version of genisoimage can have multisessions created atop them without
trouble --- but because multisession images created by the buggy
versions may be used as -M sources, we still need to work around it.

Evidence on my system suggests that this may have been a bug in Debian
cdrkit 1.1.6 and perhaps 1.1.7: the bug may have been present in other
versions, though: I don't make multisession data images often. (I
haven't verified that this is the case: the bug may be present somewhere
else, or may still be present but only active in certain circumstances.)

This somewhat kludgy workaround simply unconditionally treats '..' as a
directory. (I suspect that ISO-9660 images that have files named '..'
can't be usefully mounted on Linux systems in any case, because there's
no way to access those files at all.)

This works for me and lets me do an incremental backup from a buggy
image, but I don't know the ISO-9660 standard at all so it may cause
other interoperability problems for all I know: I do not claim this is
other than a kludge. Review solicited from someone who actually knows
the standard: I'm aware that `works for me' isn't ideal, but I needed to
get my backups done, so someone else seeing this problem might as well
benefit :)

Index: genisoimage/multi.c
===================================================================
--- genisoimage/multi.c	(revision 815)
+++ genisoimage/multi.c	(working copy)
@@ -1217,6 +1217,19 @@
 		}

 		/*
+		 * If this entry is named "." or ".." but doesn't have the directory flag
+		 * (or any other flag) on, it was written by an old (buggy) version of
+		 * genisoimage. Linux doesn't care about the value of this flag: we should
+		 * act as if it has ISO_DIRECTORY set.
+		 */
+
+		if (((pnt[i]->isorec.flags[0]) == 0) &&
+		    ((strcmp(pnt[i]->name, ".") == 0) ||
+		     (strcmp(pnt[i]->name, "..") == 0))) {
+			pnt[i]->isorec.flags[0] = ISO_DIRECTORY;
+		}
+
+                /*
 		 * Skip directories for now - these need to be treated
 		 * differently.
 		 */

submitter 446632 !
tags 446632 + unreproducible
thanks

* Nix <nix@esperi.org.uk>, 2008-09-15, 22:27:

I originally filed this bug against genisoimage 9:1.1.6-1. But today I
tried to reproduce it with the very same version of genisoimage (and the
same version of libraries genisoimage links to, and same locale), and I
couldn't. :( This means that either:
- I'm crazy, or
- I messed something up when filing the bug report, or
- the bug is indeed triggered only under special circumstances (and we
don't know what they are).

exits:

$ mkdir test/{A,B}
$ echo 'test 1' > test/A/test
$ echo 'test 2' > test/B/test
$ find test -type f > file.list
$ genisoimage  -R -path-list file.list -o test.iso # ERROR
$ genisoimage  -path-list file.list -o test.iso # OK, but does not
create sub-dirs
$ genisoimage -o test.iso test # OK, but no sub-dirs
$ genisoimage -R -o test.iso test # works OK, sub-dirs {A,B} present

version from a package of current debian-wheezy:
$ genisoimage -v
genisoimage 1.1.11 (Linux)


I hope this helps.