libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] About old branches of mine


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] About old branches of mine
Date: Mon, 3 Apr 2023 06:11:05 -0400

On Mon, Apr 3, 2023 at 5:31 AM Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> Rocky Bernstein wrote:
> > if xoriso or some other burner program in the past created ISO 9660
> images
> > in a particular way,
>
> xorriso still produces the larger ISOs by default. Normally it does not
> matter to have 300+ KiB of waste, while the advantage is safety against
> the Linux TAO CD bug and the capability for recording a multi-session
> history.
>
> Whatever, do i get it right that you want me to add the old wasteful ISO
> to test/check_multiextent.sh like this ?
>
>   for i in multi_extent_8k.iso \
>            multi_extent_8k_big.iso \
>            multi_extent_8k_joliet.iso
>   do
>     ... test ...
>
>
Yes, please do that. Thanks.


>
> Already finding a good name for the "_big" ISO is difficult. I am
>

It is not that difficult "_big" or if you want to be more correct "_larger"
is fine.


> reluctant to call it "_wasteful" because it's waste only in the context of
> libcdio tests. "_old" would be wrong too, because it is still the default
> with xorriso. But "_default" would open the question what's wrong with
> it or with the other non-default ISO.
> It boils down to the fact that i cannot give a convincing motivation for
> its existence.
>

The motivation is that these are different. Even though xorriso doesn't
create the smaller one
some other burner might.


>
> A compromise would be to replace both by an ISO which just lacks the end
> padding but has the multi-session preparation:
>

This feels like more complication than compromise.


>
>   dd bs=2048 count=96 if=multi_extent_8k_big.iso \
>                       of=multi_extent_8k.iso
>
> This would remove the end padding which is not counted as part of the ISO
> filesystem (other than results from the mkisofs emulation). The result has
> 196608 bytes rather than 524288.
> People might wonder why the ISO for the Joliet test is still smaller.
>

Add a README  file inside the "test" that describes the images, what they
are and how they were created.

That would probably be a good thing to do anyway.


>
> Have a nice day :)
>
> Thomas
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]