Re: Add genisoimage parameter -keep-top-dirs
Hi,
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:
https://code.launchpad.net/ubuntu/+source/cdrkit
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
https://packages.debian.org/unstable/genisoimage
is obviously based on
http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11.orig.tar.gz
http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11-3.2.debian.tar.xz
You may inspect the source online at
https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/
> 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
https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/debian/patches/
(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
https://github.com/torvalds/linux/blob/master/fs/isofs/util.c
Line 109 in
https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h
> 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 :)
Thomas
Reply to: