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
