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

[Ivan Shmakov]

>>>>> 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?

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