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