>>>>> On 2022-04-24, Thomas Schmitt wrote: >>>>> Ivan Shmakov wrote:
>> I’m filing this bug against versions from oldstable and stable, >> for that’s so far the only Debian packages’ versions I’ve tested >> for this issue. > As it is about an upstream wish: > The newest easily compilable and then usable version would be > http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz Not under http://ftp.gnu.org/gnu/xorriso/ , though? > It can be compiled without much dependencies and then used without > installation. See "Compilation, First Glimpse, Installation" in > https://www.gnu.org/software/xorriso/README_xorriso_devel > Said that, and now with my upstream hat on, i expect no difference > to versions 1.5.0 or 1.5.4 in respect to command -cut_out. It’d seem that I’ve missed an important detail or two in my original message. The patch suggested was against the following Git revisions of the libisofs and libisoburn: commit da00291519ad22c5bfa79c93ffeb04219bab0d7e Author: Thomas Schmitt <scdbac...@gmx.net> AuthorDate: 2022-04-23 09:32:44 +0200 Commit: Thomas Schmitt <scdbac...@gmx.net> CommitDate: 2022-04-23 09:32:44 +0200 Let the original isohybrid GPT obey system_area() option bit 17: GPT writable commit 0ef65a783765dbde79242ac41d5b9f2a495de1ec Author: Thomas Schmitt <scdbac...@gmx.net> AuthorDate: 2022-04-23 14:09:30 +0200 Commit: Thomas Schmitt <scdbac...@gmx.net> CommitDate: 2022-04-23 14:09:30 +0200 Updated change log and web page 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. > So there is no need to get xorriso-1.5.5.tar.gz unless you want > to test a patch proposed by me. I’ll be checking the master branch from time to time, and hope to test the patch and report the results once it lands there. TIA. > I downloaded your 114.xorriso-1.diff and will study it for the > goal of enabling -cut_out for more file types. > I already see that it makes changes about fsrc_open(), which is a > central facility of libisofs. This means it will last several days > of study and pondering until i would be convinced of any change. The patch was intended, first and foremost, as a proof of concept; I hope I’ve identified /where/ the code needs to be changed, but I’m not going to claim familiarity with all the code paths involved, and as such cannot readily suggest /what/ changes are needed. As it is, I fully expect for the things to break. > Also i need to check whether your diff interferes with the > ability to backup a block device file as itself and not as bearer > of its content: > rm test.iso > xorriso -outdev test.iso -map /dev/sr0 /sr0 -commit -lsdl /sr0 -- > should produce even with a loaded BD_RE medium of 23 GiB a small ISO and > report a block device file in it > brw-rw---- 1 0 24 11,0 Apr 24 14:15 '/sr0' FWIW, as a user, I’d expect an additional -follow option for this feature, such as: *seekable* If enabled, any non-regular seekable file (such as a block device) would be stored on image as a regular one with the contents taken from the original. The default is to store special files as-is. (See also the -cut_out option.) 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, thus allowing for transparent support of novel or non-standard (platform-specific) file types. -- FSF associate member #7257 http://am-1.org/~ivan/
