Bug#1010098: xorriso: please allow -cut-out directly from block devices

0 views
Skip to first unread message

Ivan Shmakov

unread,
Apr 24, 2022, 6:50:03 AMApr 24
to
Package: xorriso
Version: 1.5.0-1
Severity: wishlist
Control: found -1 1.5.2-1

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

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. Regardless, given that the
behavior is the same for a recent Git revision, and that
there doesn’t seem to be any relevant Debian-specific
patches under [1], it stands to reason that the requested
feature is not available in Debian testing and Sid, either.

[1] http://sources.debian.org/src/libisoburn/1.5.4-2/debian/patches/

It would be handy to be able to use xorriso(1) to backup
(portions) of block devices to optical media; yet it doesn’t
seem to be supported. E. g., on Buster:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
-find / -exec lsdl -- -commit
xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd4973.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with '/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$

On Bullseye:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
-find / -exec lsdl -- -commit
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd1415.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with '/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$

The problem is due to /both/ libisoburn (to a lesser degree)
and libisofs relying on struct stat .st_size field (and the
respective S_ISREG check.)

I’ve made a very crude patch (MIMEd) that replaces the
st_size checks for non-regular files with checks against the
size reported by lseek (, 0, SEEK_END), if available; and in
some cases forgoes the check for non-regular files altogether.

Consider, e. g.:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
-cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m -find / -exec lsdl -- -commit
xorriso 1.5.5 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, XXXm free
drwxr-xr-x 1 0 0 0 Apr 24 10:16 '/'
-rw-rw---- 1 0 6 13631488 Apr 10 10:58 '/lvxxx_37m+13m'
xorriso : UPDATE : Writing: 3985s 58.2% fifo 0% buf 50%
ISO image produced: 6679 sectors
Written to medium : 6848 sectors at LBA 32
Writing to 'stdio:/tmp/cd14597.image' completed successfully.

xorriso : NOTE : Re-assessing -outdev 'stdio:/tmp/cd14597.image'
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1 nodes read in 1 seconds
Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 6679 data blocks, 13.0m data, XXXm free
Volume id : 'ISOIMAGE'
bash$

Checking if the intended data was indeed written to the image
with icat(1):

bash$ /usr/bin/time -- cmp -n 13M -i 37M:0 -- \
/dev/vgjubca-bk-i/lvepeci-x626512db \
<(icat /tmp/cd14597.image 1)
0.01user 0.04system 0:00.18elapsed 29%CPU (0avgtext+0avgdata 1088maxresident)k
27112inputs+0outputs (0major+95minor)pagefaults 0swaps
bash$

--
FSF associate member #7257 http://am-1.org/~ivan/
114.xorriso-1.diff

Thomas Schmitt

unread,
Apr 24, 2022, 8:30:03 AMApr 24
to
Hi,

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
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.
So there is no need to get xorriso-1.5.5.tar.gz unless you want to
test a patch proposed by me.

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.

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'

So i guess that other changes are necessary to keep this capability while
enabling -cut_out for block devices.

I will report my findings.


Have a nice day :)

Thomas

Ivan Shmakov

unread,
Apr 24, 2022, 5:40:04 PMApr 24
to
>>>>> 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 <scdb...@gmx.net>
AuthorDate: 2022-04-23 09:32:44 +0200
Commit: Thomas Schmitt <scdb...@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 <scdb...@gmx.net>
AuthorDate: 2022-04-23 14:09:30 +0200
Commit: Thomas Schmitt <scdb...@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.

Thomas Schmitt

unread,
Apr 25, 2022, 4:30:04 AMApr 25
to
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.

Thomas Schmitt

unread,
Apr 25, 2022, 2:50:03 PMApr 25
to
Hi,

the plan to allow nearly all file types with -cut_out is dwindeling:

- lseek(SEEK_END) on S_IFCHR /dev/zero returns 0, not -1.

- open() on S_IFIFO blocks (and i don't want to know what it will do
in libisofs). IIRC a successful open() has side effects on the fifo.

- S_IFSOCK fails properly with the lseek test.
But in this case open() fails with errno 6 "No such device or address"
although it exists as file /run/user/...userid../pulse/native.
So i don't know what might happen with other sockets.

So if we exclude S_IFSOCK, S_IFLNK, S_IFDIR, S_IFIFO there remain only
S_IFREG, S_IFBLK, S_IFCHR with the latter on Linux behaving like S_IFREG
with 0 bytes of content. (As said on FreeBSD it could be a lseekable disk
device.)

Now i ponder whether i shall count S_IFCHR with size 0 as non-seekable
or really as empty file.
And whether i shall have a negative list of four types or a positive list
of three types.

Further it turned out that the lseek test in libisofs falls victim to
a bug in fs_local.c and fs_image.c which trick iso_file_source_lseek()
into returning libisofs error codes as positive off_t numbers.
A bug from the very early days of libisofs.

I am still testing but looking forward to committing the changes tomorrow.

Thomas Schmitt

unread,
Apr 26, 2022, 6:30:03 AMApr 26
to
Hi,

i decided to regard a device with 0 lseekable size as not suitable for
-cut_out. The test for suitable type rejects S_ISDIR, S_ISLNK, S_ISFIFO, and
S_ISSOCK. So if an operating system offers non-POSIX types, it will be
possible to test whether they are elsewise suitable.

Please give the code a thorough test, especially with weird -cut_out
arguments.

---------------------------------------------------------------------------
Committed are:

https://dev.lovelyhq.com/libburnia/libisofs.git

commit 011e2e85e6dfe6e5d882d198c29fd15c02d38e5e
Author: Thomas Schmitt <scdb...@gmx.net>
Date: Tue Apr 26 12:12:15 2022 +0200

Allowed lseekable device files with iso_tree_add_new_cut_out_node(). Proof-of-concept by Ivan Shmakov.

commit f457a4f8b9a59906cde1b6577e7116944a37d2d0
Author: Thomas Schmitt <scdb...@gmx.net>
Date: Tue Apr 26 12:06:18 2022 +0200

Added missing stream type names to a diagnostic function

commit 2af17490a08c29b033942da42d27b5bda076ad05
Author: Thomas Schmitt <scdb...@gmx.net>
Date: Tue Apr 26 12:03:53 2022 +0200

Bug fix: The lseek methods of IsoFileSource for local filesystem and loaded ISO returned libisofs error codes as positive off_t numbers

https://dev.lovelyhq.com/libburnia/libisoburn.git

commit fc587966d3c770be8b71e57e924cb5cbf7121f76
Author: Thomas Schmitt <scdb...@gmx.net>
Date: Tue Apr 26 12:17:22 2022 +0200

Allowed lseekable device files with -cut_out. Proof-of-concept by Ivan Shmakov.

---------------------------------------------------------------------------

Mentioning in man xorriso:
===========================================================================

Map a byte interval of a regular disk file or of a device file into a regular
file in the ISO image. The file depicted by disk_path has to support random
read access.
...
Another use case is copying the content of a device file as interval or as
a whole into the emerging ISO filesystem. The fact that the byte_count is
allowed to be unreasonably high enables copying of a whole device:
-cut_out /dev/sdd3 0 1000g /content_of_sdd3

---------------------------------------------------------------------------

Behavior with the various file types and situations:
===========================================================================
Intentional failures:
---------------------------------------------------------------------------
S_IFIFO:

xorriso : ERRFILE : /home/test/fifo
xorriso : FAILURE : -cut_out: File type (name_pipe) is not suitable for this command: '/home/test/fifo'

---------------------------------------------------------------------------
S_IFLNK:

xorriso : ERRFILE : /home/test/link
xorriso : FAILURE : -cut_out: File type (symbolic_link) is not suitable for this command: '/home/test/link'

---------------------------------------------------------------------------
S_IFSOCK:

xorriso : ERRFILE : /run/user/1000/pulse/native
xorriso : FAILURE : -cut_out: File type (unix_socket) is not suitable for this command: '/run/user/1000/pulse/native'

---------------------------------------------------------------------------
S_IFDIR:

xorriso : ERRFILE : /run/user/1000/pulse
xorriso : FAILURE : -cut_out: File type (directory) is not suitable for this command: '/run/user/1000/pulse'

---------------------------------------------------------------------------
S_IFREG not large enough:

xorriso : ERRFILE : /home/x
xorriso : SORRY : -cut_out: Byte offset 32768 larger than addressable file size 1209 : '/home/x'

---------------------------------------------------------------------------
S_IFCHR (tests are made on Linux):

xorriso : FAILURE : -cut_out: Special file with addressable size range of 0 encountered
xorriso : ERRFILE : /dev/zero
xorriso : FAILURE : -cut_out: File (char_device) does not support random read access: '/dev/zero'

---------------------------------------------------------------------------
S_IFBLK without read permission:

xorriso : FAILURE : Determination of random-access readable capacity failed: '/dev/sdb' : Permission denied
xorriso : ERRFILE : /dev/sdb
xorriso : FAILURE : -cut_out: File (block_device) does not support random read access: '/dev/sdb'

---------------------------------------------------------------------------
S_IFBLK not large enough:

xorriso : ERRFILE : /dev/sdc
xorriso : FAILURE : -cut_out: Byte offset 4294967296 larger than addressable file size 2004877312 : '/dev/sdc'

===========================================================================
Successes:
---------------------------------------------------------------------------
S_IFBLK of sufficient size:

(only a message of severity DEBUG appears, like with the others too:
xorriso : DEBUG : -cut_out from /dev/sdc , byte 1024 to 3072, and graft as /sdc
)

---------------------------------------------------------------------------
S_IFREG of sufficient size:

(only a message of severity DEBUG appears, like with the others too:
xorriso : DEBUG : -cut_out from /home/x , byte 1024 to 3072, and graft as /x
)

---------------------------------------------------------------------------

Ivan Shmakov

unread,
May 25, 2022, 10:40:04 PMMay 25
to
>>>>> On 2022-04-26, Thomas Schmitt wrote:
>>>>> TS == Thomas Schmitt wrote:

TS> So if we exclude S_IFSOCK, S_IFLNK, S_IFDIR, S_IFIFO there
TS> remain only S_IFREG, S_IFBLK, S_IFCHR with the latter on Linux
TS> behaving like S_IFREG with 0 bytes of content. (As said on
TS> FreeBSD it could be a lseekable disk device.)

I’m not familiar with FreeBSD, but at least on NetBSD block
devices are paired with character devices used for ‘raw’
access; for example, the first GPT partition may end up
being /dev/dk0 (block) and /dev/rdk0 (character); a logical
volume could be /dev/vgfoo/lvbar (block) and /dev/vgfoo/rlvbar
(character); etc.

On Linux-based systems, such a device can apparently be
created with raw(8), but it’s not something I recall ever
needing to use.

http://manpages.debian.org/bullseye/raw.8

> I decided to regard a device with 0 lseekable size as not
> suitable for -cut_out.

An alternative would be to check if it’s possible to seek to
specified positions rather than to the end of file; e. g.:

$ strace -e trace=lseek -- dd skip=5 count=7 < /dev/zero > /dev/null
lseek(0, 0, SEEK_CUR) = 0
lseek(0, 2560, SEEK_CUR) = 0
7+0 records in
7+0 records out
3584 bytes (3.6 kB, 3.5 KiB) copied, 0.00119932 s, 3.0 MB/s
+++ exited with 0 +++
$

Can’t say I can readily suggest a good use case for such a
feature, though. Should one need to add a zero-filled file
of arbitrary size to the resulting filesystem (such as to
reserve space for a possible future dd(1) there), such
a (regular) file can easily be created with truncate(1)
(though it can be argued that -cut-out /dev/zero is a tad
clearer solution.)

> The test for suitable type rejects S_ISDIR, S_ISLNK, S_ISFIFO,
> and S_ISSOCK. So if an operating system offers non-POSIX types,
> it will be possible to test whether they are elsewise suitable.

> Please give the code a thorough test, especially with weird
> -cut_out arguments.

This looks like a job for a test suite. I gather there’s
none as of yet?

Meanwhile, I’ve noticed that the files created via -cut-out
inherit the permissions and m-time of the original file.
The former might be reasonable, but the latter doesn’t seem
to make much sense, at least for device files (whose m-times
tend to have no relation to their content proper.)

Worse still, if the target file is created in a yet-nonexistent
directory, the directory created inherits the permissions
of the source file as well (only adding +x where there’s r.)
I’d rather expect for missing directories to be created as
if with -mkdir.

Thoughts?

Thomas Schmitt

unread,
May 26, 2022, 9:00:04 AMMay 26
to
Hi,

Ivan Shmakov wrote:
> An alternative would be to check if it’s possible to seek to
> specified positions rather than to the end of file; e. g.:

I see at least the problem that the end position of -cut_out
(byte_offset + byte_count + 1) is allowed to be unrealisticly high in
order to simply address the end of the file.
This means that xorriso and libisofs need to know this end.

I will have to think whether a file is usable which does not return
success on lseek(,,SEEK_END) but on lseek(,desired_size,SEEK_SET)
... and whether all size inquirers can know the desired_size ...


> > Please give the code a thorough test, especially with weird
> -cut_out arguments.

> This looks like a job for a test suite. I gather there’s
> none as of yet?

There were visits by the American Fuzzy Lop.
It is an art of its own to design tests which catch unexpected bugs.


> Meanwhile, I’ve noticed that the files created via -cut-out
> inherit the permissions and m-time of the original file.
> The former might be reasonable, but the latter doesn’t seem
> to make much sense, at least for device files (whose m-times
> tend to have no relation to their content proper.)

It's for backup fidelity. osirrox command -paste_in can be used to restore
a file that was stored as several -cut_out pieces.

(This raises the question whether -paste_in works with devices ...
... No, it insists in regular files. Another thing to think about.)

If you want other timestamps, use command -alter_date (+0 = right now).


> Worse still, if the target file is created in a yet-nonexistent
> directory, the directory created inherits the permissions
> of the source file as well (only adding +x where there’s r.)

This looks like a bug. Actually it should copy the permissions from the
parent directories in the -cut_out disk_path, like command -map does.
But indeed the non-x permissions are taken from the data file itself.
I will investigate (and try to remember what i did 14 years ago, as
i suspect command -split_size to be the regular customer of this surprise
feature).

Thomas Schmitt

unread,
Jun 2, 2022, 10:40:03 AMJun 2
to
Hi,

Ivan Shmakov wrote:
> An alternative would be to check if it’s possible to seek to
> specified positions rather than to the end of file

This should work now, by an attempt of lseek(wanted_size, SEEK_SET) if
lseek(0, SEEK_END) yields failure or 0 size.
(libisoburn commit 0c0d542, libisofs commit c6cb7df)

Nevertheless, the attempt to read from /dev/zero still yields failure,
because lseek() returns 0 when it is supposed to return the new offset
position.
This is already so in your example with strace and dd:
> lseek(0, 2560, SEEK_CUR) = 0

Actually i think that the behavior of lseek() with /dev/zero is not
conformant with man 2 lseek:

RETURN VALUE
Upon successful completion, lseek() returns the resulting offset loca‐
tion as measured in bytes from the beginning of the file. On error,
the value (off_t) -1 is returned.

The xorriso code does not ask for offset 0. So the lseek() call does not
succeed if the resulting offset is 0. So the return value should be -1.


If non-random-access file content is desired and can be produced with
repeatable size, then consider to define a filter by -external_filter
and attach it to a file by -set_filter. The file may be inserted with an
arbitrary file as source. The filter program is free to ignore it and to
do its own thing.

-------------------------------------------------------------------

> if the target file is created in a yet-nonexistent
> directory, the directory created inherits the permissions
> of the source file as well (only adding +x where there’s r.)

This is an intentional feature introduced in 2008. SVN rev 1643, now git
commit a44e7db9:
Bug fix: Implicite directory attribute copying with -cut_out was wrong
There are reasons why this makes sense if the disk file's permissions
are restrictive and its parent's permissions are liberal.

Embarrassingly, only a week later i introduced automatic file splitting,
controlled by command -split_size, where this peculiar source of directory
permissions would make even more sense.
But function Xorriso_graft_split() inserts a new directory with the
permissions of the parent directory in the ISO.

I have now corrected this to the behavior of -cut_out and documented it
with both commands in the man page:

-cut_out disk_path byte_offset byte_count iso_rr_path
...
E.g.
...
-cut_out /my/disk/file 4094m 2047m \
/file/part_3_of_3_at_4094m_with_2047m_of_5753194821
If the directory /file does no yet exist, then its permissions
are not taken from directory /my/disk but rather from
/my/disk/file with additional x-permission for those who have
r-permission.
...
-split_size number["k"|"m"]
...
The newly created ISO directory inherits its permissions from
the data file with additional x-permission for those who have
r-permission.

(libisoburn commit 5aac3dd)

-------------------------------------------------------------------

Then there was the problem of -paste_in not working with devices which
are suitable for -cut_out (and thus not being the reverse operation of
-cut_out).
I changed -paste_bin so that it is willing to work with the same files
as target which -cut_out would accept as source (modulo permissions, of
course).
(libisoburn commit 865115f)
Reply all
Reply to author
Forward
0 new messages