[Pkg-libburnia-devel] Bug#1010098: xorriso: please allow -cut-out directly from block devices

[Thomas Schmitt]

Hi,

i wrote:
> > The newest easily compilable and then usable version would be
> >   http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz

Ivan Shmakov wrote:
>         Not under http://ftp.gnu.org/gnu/xorriso/ , though?

1.5.5 is a development snapshot with potentially later changing new features
of the APIs of the library code and with potentially later changing new
xorriso commands or command parameters.
Distros should not distribute it.
In GNU ftp it has no place because its content changes in the course of the
development cycle between the latest release 1.5.4 und the future release
1.5.6.


> I’d frankly be surprised to learn that a proper release,
> such as 1.5.5, has features which a recent revision from
> Git master branch lacks.

The development snapshot gets composed by
  libisoburn/xorriso/make_xorriso_standalone.sh
from my local copy of the repos when it seems ready for public testing.
It can happen that the repos are ahead of the snapshot tarball. But as of
today, the tarball is at the same state as the repos.
(It was uploaded on 23 Apr 2022.)


> I’ll be checking the master branch from time to time,

This is ok, although the tarball is easier to compile and needs no
installation of any freshly produced dynamic libraries because its library
code gets linked statically.
Whatever, better wait until i announce that it is time for testing.


> The patch was intended, first and foremost, as a proof of concept;

As such it appears to be very good. My only scruples so far are about
touching fsrc_open() which serves for the main use cases of libisofs and
thus would need intense testing of those cases.

I am now testing a variation which puts the changes into the code of the
cut_out_*() functions in libisofs/stream.c rather than faking the value
of struct stat.st_size .
This will hopefully keep all other use cases safe.

The new use case of copying the whole content of a device will then be a
special case of -cut_out exploiting the rule in man xorriso:
  "It is permissible to request a higher byte_count than available."
E.g.
  -cut_out /dev/XYZ 0 1000g /ABC


> In the implementation, I’d rather see it not testing the
> file type specifically, aside of S_ISREG, S_ISDIR and S_ISLNK,
> but rather whether lseek (, 0, SEEK_END) gives a sane result,

Yes. I first was sceptical about allowing nearly all file types although
on Linux only S_IFREG and S_IFBLK give hope for seekability. But on FreeBSD
all devices files identify as S_IFCHR.
(Equivalent to Linux block devices are those which reply success of
ioctl(DIOCGMEDIASIZE). At least i got no complaints that libburn would
misclassify BSD devices as random-access pseudo-drives when they are
actually just sequentially writable.)

So overall it seems best to let just lseek(2) decide what goes and what
doesn't.


Have a nice day :)

Thomas