[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Add genisoimage parameter -keep-top-dirs


Kai Engert wrote:
> If growisofs is going to survive for another few years, then maybe it's
> worth keeping the toolchain alive? (which requires genisoimage)

xorriso can substitue for mkisofs and genisoimage by help of its link
"xorrisofs" and the growisofs variable "MKISOFS". man xorrisofs has
an example:

    $ export MKISOFS="xorrisofs"
    $ growisofs -Z /dev/dvd /some/files
    $ growisofs -M /dev/dvd /more/files
  If  no  "xorrisofs"  is available on your system, then you will have to
  create a link pointing to the xorriso binary and tell growisofs to  use
  it. E.g. by:
    $ ln -s $(which xorriso) "$HOME/xorrisofs"
    $ export MKISOFS="$HOME/xorrisofs"

> Is there a primary repository somewhere (e.g. github) that is equivalent to
> the most recent cdrkit release that debian and fedora packages are based on?

The original repo is gone, i fear.
This here looks like going back to the fork from cdrtools in 2006:

It knows my Launchpad Id and offers
  git clone git+ssh://scdbackup@git.launchpad.net/ubuntu/+source/cdrkit
I guess you get at least offered
  git clone https://git.launchpad.net/ubuntu/+source/cdrkit

> Is there an official download location for the most recent tar archive, or
> would it be fine to simple use the archive found in the debian package?

The most recent Debian package
is obviously based on
You may inspect the source online at

> Maybe Sam's other changes should be ignored / kept separate.

At least other changes should be kept out of the game until you unpacked
the original source, applied at least the two bitrot patches from
(namely "fix_libcap_detection.patch" and "gcc10.patch".),
and managed to build the binaries.

> Regarding the 2038 issue and time64_t, you referred to a iso_date function
> and to a filename that I cannot find in the cdrkit archive.

That bug sits in the Linux kernel. Line 19 and 22 in
Line 109 in

> Regardless, is my understanding correct that the 2038 bug will be limited to
> 32bit platforms, because on 64bit platforms time_t is already sufficiently
> big to avoid the 2038 bug?

The current type is int, not time_t. I don't expect that int will
become 64 bit on the then mainstream architectures before kernels get
compiled which are expected to be still on duty when 2038 arrives.

I have a patch with demonstration of the problem by

  xorriso -outdev /tmp/test_date.iso \
          -blank as_needed \
          -map /bin/true /victim \
          -alter_date m 'Oct 01 22:06:12 2040' /victim --

When mounted the kernel returns the victim's timestamp as
  Aug 26  1904

But i gave up on submitting Linux patches after even a kernel Oops on
powerpc64 was ignored.

Maybe i learn to know somebody until 2038 who has the standing to get
at least a review for a patch submission.
(Another isofs bug is about Rock Ridge names of byte length 254 or 255,
which get shown massively truncateid by Linux - up to name collisions.
More bugs are around in cdrom and sr.)

Have a nice day :)


Reply to: