* Re: unshare regression in 2.42-rc1
From: Chris Hofstaedtler @ 2026-03-26 14:01 UTC (permalink / raw)
To: Christian Albrecht Goeschel Ndjomouo
Cc: Karel Zak, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, util-linux@vger.kernel.org,
Helmut Grohne
In-Reply-To: <SJ0P220MB05417CC33D6BA305A9CEE320E94AA@SJ0P220MB0541.NAMP220.PROD.OUTLOOK.COM>
Hi Christian,
* Christian Albrecht Goeschel Ndjomouo <cgoesc2@wgu.edu> [260322 13:57]:
>Thank you for pointing out this regression.
>
>The problem is that if ul_getuserpw_str() cannot find any user with the provided
>UID or username, the unshare internal helper function get_user() will error out
>and stop argument parsing, even if a valid numeric value was provided. Previously,
>the code would fallback to simply converting the string to an unsigned int and use
>it for the uid_t, so I added that behavior back.
>
>I found this issue to be true for the --map-group option as well, so I went ahead and fixed
>both cases in this latest patch: https://github.com/util-linux/util-linux/pull/4134/changes/c74df906b67b2f9930662ca4e1ba04c21569d529
>
>Please let us know if this fixed the problem on your end.
With the patch applied, the debvm tests succeed once again.
So this seems good.
I see Karel has in the meantime merged a different approach. I'll
recheck with 2.42-rc2.
Thank you,
Chris
^ permalink raw reply
* the bad effect of tables on msgids
From: Benno Schulenberg @ 2026-03-24 15:49 UTC (permalink / raw)
To: Util-Linux, Karel Zak, Mario Blättermann
[-- Attachment #1.1: Type: text/plain, Size: 1681 bytes --]
Hi,
Comparing the POT file for the manual of the upcoming v2.42 with the previous
one at the TP, I notice (among other things) the replacement of this msgid:
msgid ""
" f: = the pathname currently being resolved\n"
" d = directory\n"
" l = symbolic link (both the link and its contents are output)\n"
" s = socket\n"
" b = block device\n"
" c = character device\n"
" p = FIFO (named pipe)\n"
" - = regular file\n"
" ? = an error of some kind\n"
with the far longer one below. It seems to me that the above one is easier
to translate (because clearer, more comprehensible, with a simpler structure)
than the one below. So... changing simple lists to tables 1) more than triples
the space that the information takes up on the manpage, making it less easily
digestible, AND 2) makes it harder to translate. I don't see any advantages to
using tables. If there are any, please enlighten me.
msgid ""
"|f:\n"
"|the pathname currently being resolved\n"
"\n"
"|d\n"
"|directory\n"
"\n"
"|l\n"
"|symbolic link (both the link and its contents are output)\n"
"\n"
"|s\n"
"|socket\n"
"\n"
"|b\n"
"|block device\n"
"\n"
"|c\n"
"|character device\n"
"\n"
"|p\n"
"|FIFO (named pipe)\n"
"\n"
"|-\n"
"|regular file\n"
"\n"
"|?\n"
"|an error of some kind\n"
(The above change was the effect of commit a8616d1a76 from three weeks ago
by Mario.)
If there are no advantages to using tables instead of lists, please revert
to using lists for simple "tabular" listings of information.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* [ANNOUNCE] util-linux v2.42-rc2
From: Karel Zak @ 2026-03-24 11:42 UTC (permalink / raw)
To: util-linux
The util-linux release v2.42-rc2 is now available at
http://www.kernel.org/pub/linux/utils/util-linux/v2.42
Feedback and bug reports, as always, are welcomed.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] test_enosys: Handle musl libc error strings
From: Karel Zak @ 2026-03-23 13:32 UTC (permalink / raw)
To: Anna Wilcox; +Cc: util-linux, Sam James
In-Reply-To: <20260323030358.59511-1-AWilcox@Wilcox-Tech.com>
On Sun, Mar 22, 2026 at 10:03:52PM -0500, Anna Wilcox wrote:
> strerror(3) on musl gives different strings for some of the errnos we
> test for, so the tests incorrectly fail on musl. Change the strings
> back into the glibc ones so they match the expected values properly.
>
> Signed-off-by: Anna Wilcox <AWilcox@Wilcox-Tech.com>
> Suggested-by: Sam James <sam@gentoo.org>
> ---
> tests/ts/enosys/enosys | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/tests/ts/enosys/enosys b/tests/ts/enosys/enosys
> index 591b292a8..698283056 100755
> --- a/tests/ts/enosys/enosys
> +++ b/tests/ts/enosys/enosys
> @@ -20,6 +20,12 @@ TS_DESC="enosys"
> . "$TS_TOPDIR"/functions.sh
> ts_init "$*"
>
> +function ts_canonicalise_strerror {
> + sed -Ei -e 's/Out of memory/Cannot allocate memory/g' \
> + -e 's/Not a tty/Inappropriate ioctl for device/g' \
> + -e 's/No error information/Success/g' $1
> +}
For something like this we already use
tests/helpers/test_strerror.c
for example (git grep result):
tests/ts/fdisk/oddinput:ts_check_test_command "$TS_HELPER_STRERROR"
tests/ts/fdisk/oddinput:sed -i -e "s@$($TS_HELPER_STRERROR ENOENT)@ENOENT@" $TS_OUTPUT $TS_ERRLOG
tests/ts/fdisk/oddinput:sed -i -e "s@$($TS_HELPER_STRERROR EINVAL)@EINVAL@" $TS_OUTPUT $TS_ERRLOG
It replaces the error message with the errno abbreviation.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] test_enosys: Handle musl libc error strings
From: Anna Wilcox @ 2026-03-23 3:03 UTC (permalink / raw)
To: util-linux; +Cc: Anna Wilcox, Sam James
strerror(3) on musl gives different strings for some of the errnos we
test for, so the tests incorrectly fail on musl. Change the strings
back into the glibc ones so they match the expected values properly.
Signed-off-by: Anna Wilcox <AWilcox@Wilcox-Tech.com>
Suggested-by: Sam James <sam@gentoo.org>
---
tests/ts/enosys/enosys | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/tests/ts/enosys/enosys b/tests/ts/enosys/enosys
index 591b292a8..698283056 100755
--- a/tests/ts/enosys/enosys
+++ b/tests/ts/enosys/enosys
@@ -20,6 +20,12 @@ TS_DESC="enosys"
. "$TS_TOPDIR"/functions.sh
ts_init "$*"
+function ts_canonicalise_strerror {
+ sed -Ei -e 's/Out of memory/Cannot allocate memory/g' \
+ -e 's/Not a tty/Inappropriate ioctl for device/g' \
+ -e 's/No error information/Success/g' $1
+}
+
ts_check_test_command "$TS_HELPER_ENOSYS"
ts_check_enosys_syscalls fallocate fsopen execve
@@ -34,6 +40,8 @@ $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
"$TS_CMD_ENOSYS" --syscall fallocate:12 $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
"$TS_CMD_ENOSYS" --syscall fallocate:ENOMEM $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
+ts_canonicalise_strerror "$TS_OUTPUT"
+
ts_finalize_subtest
ts_init_subtest exec
@@ -43,6 +51,8 @@ FALLOCATE_TEST="$TS_HELPER_ENOSYS exec"
$FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
"$TS_CMD_ENOSYS" --syscall execve $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
+ts_canonicalise_strerror "$TS_OUTPUT"
+
ts_finalize_subtest
ts_init_subtest ioctl
@@ -57,6 +67,8 @@ $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
"$TS_CMD_ENOSYS" --ioctl FIOCLEX:12 $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
"$TS_CMD_ENOSYS" --ioctl FIOCLEX:ENOMEM $FALLOCATE_TEST > /dev/null 2>> "$TS_OUTPUT"
+ts_canonicalise_strerror "$TS_OUTPUT"
+
ts_finalize_subtest
ts_finalize
--
2.52.0
^ permalink raw reply related
* Re: unshare regression in 2.42-rc1
From: Christian Albrecht Goeschel Ndjomouo @ 2026-03-22 12:57 UTC (permalink / raw)
To: Chris Hofstaedtler, Karel Zak
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
util-linux@vger.kernel.org, Helmut Grohne
In-Reply-To: <ab_SfC1JDOhNmg6D@zeha.at>
Hi Chris,
Thank you for pointing out this regression.
The problem is that if ul_getuserpw_str() cannot find any user with the provided
UID or username, the unshare internal helper function get_user() will error out
and stop argument parsing, even if a valid numeric value was provided. Previously,
the code would fallback to simply converting the string to an unsigned int and use
it for the uid_t, so I added that behavior back.
I found this issue to be true for the --map-group option as well, so I went ahead and fixed
both cases in this latest patch: https://github.com/util-linux/util-linux/pull/4134/changes/c74df906b67b2f9930662ca4e1ba04c21569d529
Please let us know if this fixed the problem on your end.
Regards,
Christian Goeschel Ndjomouo
________________________________________
From: Chris Hofstaedtler <zeha@debian.org>
Sent: Sunday, March 22, 2026 7:37 AM
To: Karel Zak
Cc: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; util-linux@vger.kernel.org; Christian Albrecht Goeschel Ndjomouo; Helmut Grohne
Subject: unshare regression in 2.42-rc1
Hi Karel, Christian,
Debian CI found a regression in the unshare command when using
--map-user with numeric UIDs. This worked in 2.41 and earlier:
% unshare --version && unshare --user --map-auto --map-user=65536 id
unshare from util-linux 2.41.3
uid=65536 gid=65534(nogroup) groups=65534(nogroup)
And is broken in 2.42-rc1:
% unshare --version && unshare --user --map-auto --map-user=65536 id
unshare from util-linux 2.42-rc1
unshare: failed to parse uid '65536'
Note the following (true in both cases):
$ grep 65536 /etc/passwd
%
I suspect (but did not verify yet) this was introduced in
commit 0a7fb806118bc4418e231081bd13c69bbc31b988
> unshare: use the new ul_get{grp,userpw}_str() routines
>
> This change refactors get_group() and get_user(), so that it
> uses the new routines ul_getgrp_str() and ul_getuserpw_str(),
> to simplify the code and remove the overkill mem allocations.
https://github.com/util-linux/util-linux/commit/0a7fb806118bc4418e231081bd13c69bbc31b988<https://github.com/util-linux/util-linux/commit/0a7fb806118bc4418e231081bd13c69bbc31b988>
Thanks to Helmut Grohne for reducing the failed debvm CI run to the
short unshare command.
Best,
Chris
^ permalink raw reply
* unshare regression in 2.42-rc1
From: Chris Hofstaedtler @ 2026-03-22 11:37 UTC (permalink / raw)
To: Karel Zak
Cc: linux-kernel, linux-fsdevel, util-linux,
Christian Goeschel Ndjomouo, Helmut Grohne
In-Reply-To: <wid276gkq7tblvkfwc6kum4nacamstiigqjj5ux6j6zd4blz4l@jzq3sgfh6cj5>
Hi Karel, Christian,
Debian CI found a regression in the unshare command when using
--map-user with numeric UIDs. This worked in 2.41 and earlier:
% unshare --version && unshare --user --map-auto --map-user=65536 id
unshare from util-linux 2.41.3
uid=65536 gid=65534(nogroup) groups=65534(nogroup)
And is broken in 2.42-rc1:
% unshare --version && unshare --user --map-auto --map-user=65536 id
unshare from util-linux 2.42-rc1
unshare: failed to parse uid '65536'
Note the following (true in both cases):
$ grep 65536 /etc/passwd
%
I suspect (but did not verify yet) this was introduced in
commit 0a7fb806118bc4418e231081bd13c69bbc31b988
> unshare: use the new ul_get{grp,userpw}_str() routines
>
> This change refactors get_group() and get_user(), so that it
> uses the new routines ul_getgrp_str() and ul_getuserpw_str(),
> to simplify the code and remove the overkill mem allocations.
https://github.com/util-linux/util-linux/commit/0a7fb806118bc4418e231081bd13c69bbc31b988
Thanks to Helmut Grohne for reducing the failed debvm CI run to the
short unshare command.
Best,
Chris
^ permalink raw reply
* Re: [PATCH 1/2] copyfilerange: wrap some overlong lines (in a tabsize-independent way)
From: Karel Zak @ 2026-03-19 9:42 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Dick Marinus
In-Reply-To: <20260316110938.5119-1-bensberg@telfort.nl>
On Mon, Mar 16, 2026 at 12:09:37PM +0100, Benno Schulenberg wrote:
> misc-utils/copyfilerange.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
Both patches merged. Thanks!
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH 2/2] copyfilerange: simply report "too few arguments", not misleading messages
From: Benno Schulenberg @ 2026-03-16 11:09 UTC (permalink / raw)
To: util-linux; +Cc: Dick Marinus
In-Reply-To: <20260316110938.5119-1-bensberg@telfort.nl>
Running ./copyfilerange without any arguments would report:
copyfilerange: source file is required
giving the impression that only a source file is required.
But running ./copyfilerange with one argument would report:
copyfilerange: destination file is required
giving the impression that specifying two files would be enough.
But running ./copyfilerange with two arguments would report:
copyfilerange: nothing to do, no ranges supplied
Instead of these custom messages, let's report what other tools
report when given too few arguments: "too few arguments".
This change also prevents `copyfilerange` from creating an empty
destination file when given just two arguments, when it reported
that there was nothing to do.
Furthermore, correct a parameter of a call of err(),
from `argv[2]` to `range.out_filename`.
CC: Dick Marinus <dick@mrns.nl>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/copyfilerange.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/misc-utils/copyfilerange.c b/misc-utils/copyfilerange.c
index 71b21bb28..2ebe43b3b 100644
--- a/misc-utils/copyfilerange.c
+++ b/misc-utils/copyfilerange.c
@@ -244,27 +244,20 @@ int main(const int argc, char **argv)
range.out_filename = argv[rem_optind];
}
- if (!range.in_filename)
- errx(EXIT_FAILURE, _("source file is required"));
-
- if (!range.out_filename)
- errx(EXIT_FAILURE, _("destination file is required"));
+ if (!range.out_filename || (rem_optind == argc && !nrange_files))
+ errx(EXIT_FAILURE, _("too few arguments"));
range.in_fd = open(range.in_filename, O_RDONLY);
if (range.in_fd < 0)
err(EXIT_FAILURE, _("cannot open source %s"), range.in_filename);
-
if (fstat(range.in_fd, &sb) == -1)
err(EXIT_FAILURE, _("cannot determine size of source file %s"), range.in_filename);
range.in_st_size = sb.st_size;
range.out_fd = open(range.out_filename, O_WRONLY | O_CREAT, 0666);
if (range.out_fd < 0)
- err(EXIT_FAILURE, _("cannot open destination %s"), argv[2]);
-
- if (rem_optind == argc && !nrange_files)
- errx(EXIT_FAILURE, _("nothing to do, no ranges supplied"));
+ err(EXIT_FAILURE, _("cannot open destination %s"), range.out_filename);
if (nrange_files)
handle_range_files(&range, nrange_files, range_files);
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] copyfilerange: wrap some overlong lines (in a tabsize-independent way)
From: Benno Schulenberg @ 2026-03-16 11:09 UTC (permalink / raw)
To: util-linux; +Cc: Dick Marinus
Most tools in util-linux seem to assume a tabsize of 8, judging from
the alignments of several continuation lines. But `copyfilerange.c`
appears to have assumed a tabsize of 2, because with a tabsize of 8
the text on line 147 started in column 209!
But even with a tabsize of 2, three lines were much wider than the
reasonable 100 columns. So, wrap those, and in the bargain improve
the wording of the affected messages, and add a space before %m.
CC: Dick Marinus <dick@mrns.nl>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/copyfilerange.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/misc-utils/copyfilerange.c b/misc-utils/copyfilerange.c
index 20f0373bd..71b21bb28 100644
--- a/misc-utils/copyfilerange.c
+++ b/misc-utils/copyfilerange.c
@@ -135,19 +135,23 @@ static void copy_range(struct rangeitem *range) {
uintmax_t remaining = range->length;
if (range->in_offset > range->in_st_size)
- errx(EXIT_FAILURE, _("%s offset %"PRId64" beyond file size of %"PRId64""), range->in_filename, range->in_offset, range->in_st_size);
+ errx(EXIT_FAILURE, _("%s offset %"PRId64" is beyond file size of %"PRId64""),
+ range->in_filename, range->in_offset, range->in_st_size);
while (remaining > 0) {
const size_t chunk = remaining > SIZE_MAX ? SIZE_MAX : remaining;
if (verbose)
- printf("copy_file_range %s to %s %"PRId64":%"PRId64":%zu\n", range->in_filename,
- range->out_filename, range->in_offset, range->out_offset, chunk);
+ printf("copy_file_range %s to %s %"PRId64":%"PRId64":%zu\n",
+ range->in_filename, range->out_filename,
+ range->in_offset, range->out_offset, chunk);
- const ssize_t copied = copy_file_range(range->in_fd, &range->in_offset, range->out_fd,
- &range->out_offset, chunk, 0);
+ const ssize_t copied = copy_file_range(range->in_fd, &range->in_offset,
+ range->out_fd, &range->out_offset, chunk, 0);
if (copied < 0)
- errx(EXIT_FAILURE, _("failed copy file range %"PRId64":%"PRId64":%ju from %s to %s with remaining %ju:%m\n"),
- range->in_offset, range->out_offset, range->length, range->in_filename, range->out_filename, remaining);
+ errx(EXIT_FAILURE, _("failed to copy range %"PRId64":%"PRId64":%ju "
+ "from %s to %s with %ju remaining: %m\n"),
+ range->in_offset, range->out_offset, range->length,
+ range->in_filename, range->out_filename, remaining);
if (copied == 0)
break;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Karel Zak @ 2026-03-16 10:58 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Sumanth Korikkar
In-Reply-To: <20260307114308.7517-2-bensberg@telfort.nl>
On Sat, Mar 07, 2026 at 12:43:08PM +0100, Benno Schulenberg wrote:
> sys-utils/lsmem.1.adoc | 65 +++++++++++++++++++-----------------------
> 1 file changed, 29 insertions(+), 36 deletions(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/2 V2] copyfilerange: (usage) correct the markup and improve the wording
From: Karel Zak @ 2026-03-16 10:57 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Dick Marinus
In-Reply-To: <20260312155532.52342-1-bensberg@telfort.nl>
On Thu, Mar 12, 2026 at 04:55:31PM +0100, Benno Schulenberg wrote:
> V2: Use the standard USAGE_ARGUMENTS header instead of an
> unusually placed lone paragraph.
> ---
> misc-utils/copyfilerange.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)
Both patches have been applied. Thank you.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Sumanth Korikkar @ 2026-03-13 8:23 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: Karel Zak, util-linux
In-Reply-To: <06c01b55-64ed-4aa3-9c28-f450fd1141f7@telfort.nl>
On Thu, Mar 12, 2026 at 04:59:29PM +0100, Benno Schulenberg wrote:
>
> Op 11-03-2026 om 13:27 schreef Karel Zak:
> > What I find relevant is "previously configured." Maybe add a sentence
> > stating that CONFIGURED and MEMMAP-ON-MEMORY for _offline_ blocks show
> > the previous setup.
> >
> > Benno, what do you think?
>
> I think Sumanth has agreed that my original 2/2 lsmem patch is fine
> with him.
Fine with me.
Thanks,
Sumanth
^ permalink raw reply
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Benno Schulenberg @ 2026-03-12 15:59 UTC (permalink / raw)
To: Karel Zak, Sumanth Korikkar; +Cc: util-linux
In-Reply-To: <d6fywjkl5vvef3uyshxi477fe6vtnzygb7sjsy5mecs7c546gd@cy73pfohzucq>
[-- Attachment #1.1: Type: text/plain, Size: 343 bytes --]
Op 11-03-2026 om 13:27 schreef Karel Zak:
> What I find relevant is "previously configured." Maybe add a sentence
> stating that CONFIGURED and MEMMAP-ON-MEMORY for _offline_ blocks show
> the previous setup.
>
> Benno, what do you think?
I think Sumanth has agreed that my original 2/2 lsmem patch is fine
with him.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Benno Schulenberg @ 2026-03-12 15:58 UTC (permalink / raw)
To: Sumanth Korikkar, Karel Zak; +Cc: util-linux
In-Reply-To: <abFtIOGI3eO0Sskk@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 480 bytes --]
Op 11-03-2026 om 14:24 schreef Sumanth Korikkar:
> On Wed, Mar 11, 2026 at 01:27:03PM +0100, Karel Zak wrote:
>> However, in this case, I'm not sure if the description adds anything,
>> as it repeats what is obvious from STATE, CONFIGURED, MEMMAP-ON-MEMORY
>> columns.
>
> Thanks for the feedback. In that case, we can drop the
> table and keep the sentence which was proposed earlier.
So... you're saying the original 2/2 lsmem patch is fine as it is?
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* [PATCH 2/2] copyfilerange: (man) correct the markup and improve the wordings
From: Benno Schulenberg @ 2026-03-12 15:55 UTC (permalink / raw)
To: util-linux; +Cc: Dick Marinus
In-Reply-To: <20260312155532.52342-1-bensberg@telfort.nl>
CC: Dick Marinus <dick@mrns.nl>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
misc-utils/copyfilerange.1.adoc | 61 ++++++++++++++-------------------
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/misc-utils/copyfilerange.1.adoc b/misc-utils/copyfilerange.1.adoc
index 4d214f4db..303a1a7b2 100644
--- a/misc-utils/copyfilerange.1.adoc
+++ b/misc-utils/copyfilerange.1.adoc
@@ -4,54 +4,43 @@
:man manual: User Commands
:man source: util-linux {release-version}
:page-layout: base
-:range: copyfilerange
+:command: copyfilerange
== NAME
-copyfilerange - Copy file ranges from source to destination file.
+copyfilerange - copy range(s) from source to destination file
== SYNOPSIS
-*copyfilerange* [options] [<source>] [<destination>] [<range>...]
+*copyfilerange* [options] _source_ _destination_ _range_...
== DESCRIPTION
-*copyfilerange* copy file ranges from source to destination file
-*copyfilerange* is a simple utility to call the *copy_file_range*(2) system call.
+The *copyfilerange* command copies byte ranges from source to destination file.
+It is a wrapper around the *copy_file_range*(2) system call.
-It can be used write files with unallocated gaps (sparse files) and/or share blocks between multiple files (reflinks).
+The command can be used to create files with unallocated gaps (sparse files)
+and/or with shared blocks between multiple files (reflinks).
-== ARGUMENTS
+Each _range_ is of the form _source_offset_**:**_destination_offset_**:**_length_,
+with all values in bytes. If _length_ is 0, then as much data as is available is
+copied. Multiple ranges may be supplied.
-*source*::
-Source filename
-
-*destination*::
-Destination filename
-
-*range*::
-
-Consists of a range specified as *source_offset:dest_offset:length*
-
-All values are in bytes, if length is set to 0 copy as much as available.
-Multiple range can be supplied.
-
-When one or more of the offsets are omitted the operation will use the last used location, starting with 0
+When one or both of the offsets are omitted, the operation uses the last-used
+file location, starting with 0.
== OPTIONS
-*-v*, *--verbose*::
-Verbose output of copied file ranges
+*-r*, *--ranges* _file_::
+Read range(s) separated by newlines from this _file_.
-*-r*, *--ranges*::
-Ranges filename
+*-v*, *--verbose*::
+Verbose output of the copied ranges.
include::man-common/help-version.adoc[]
== EXIT STATUS
-*copyfilerange* has the following exit status values:
-
*0*::
success
*1*::
@@ -59,7 +48,7 @@ unspecified failure
== NOTES
-The *copy_file_range*(2) system call has some serious caveats, the source and destination files must use the same filesystem type and some virtual filesystems (like procfs) won't work. *copy_file_range*(2) will use reflinks when the filesystem supports this. To use reflinks the file range most often needs to align with the filesystem block size on both the source and destination file.
+The *copy_file_range*(2) system call has some serious caveats: the source and destination files must use the same filesystem type, and some virtual filesystems (like procfs) won't work. *copy_file_range*(2) will use reflinks when the filesystem supports this. To use reflinks, the file range most often needs to align with the filesystem block size on both the source and destination file.
== AUTHORS
@@ -68,21 +57,21 @@ mailto:dick@mrns.nl[Dick Marinus]
== EXAMPLES
....
-~$ copyfilerange original-file reflink ::
+copyfilerange original-file reflink ::
-~$ copyfilerange original-file first-block ::4096
+copyfilerange original-file first-block ::4096
-~$ copyfilerange original-file even-blocks -r <(seq 0 8192 40960|awk '{print $1"::4096"}')
+copyfilerange original-file even-blocks -r <(seq 0 8192 40960|awk '{print $1"::4096"}')
-~$ copyfilerange original-file sparse-file 0:1M:1
+copyfilerange original-file sparse-file 0:1M:1
-~$ copyfilerange original-file split-first-mb ::1M
+copyfilerange original-file split-first-mb ::1M
-~$ copyfilerange original-file split-remainder 1M::
+copyfilerange original-file split-remainder 1M::
-~$ copyfilerange split-first-mb join ::
+copyfilerange split-first-mb join ::
-~$ copyfilerange split-remainder join 1M::
+copyfilerange split-remainder join 1M::
....
== SEE ALSO
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2 V2] copyfilerange: (usage) correct the markup and improve the wording
From: Benno Schulenberg @ 2026-03-12 15:55 UTC (permalink / raw)
To: util-linux; +Cc: Dick Marinus
The <source>, <destination>, and <range> arguments are required,
so do not mark them as optional (with the square brackets).
Also, trim the redundant lines about the source and destination
files, improve the explanation for the <range> argument and put
it after the options, and keep the text within 80 columns.
Furthermore, list the short options first (as is custom), and
match the indentaion of the -h and -V options to the others.
CC: Dick Marinus <dick@mrns.nl>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
V2: Use the standard USAGE_ARGUMENTS header instead of an
unusually placed lone paragraph.
---
misc-utils/copyfilerange.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/misc-utils/copyfilerange.c b/misc-utils/copyfilerange.c
index 20f0373bd..5ee562d22 100644
--- a/misc-utils/copyfilerange.c
+++ b/misc-utils/copyfilerange.c
@@ -55,25 +55,23 @@ static void __attribute__((__noreturn__)) usage(void)
FILE *out = stdout;
fputs(USAGE_HEADER, out);
fprintf(out,
- _(" %1$s [options] [<source>] [<destination>] [<range>...]\n"),
+ _(" %1$s [options] <source> <destination> <range>...\n"),
program_invocation_short_name);
fputs(USAGE_SEPARATOR, out);
- fputsln(_("Copy file ranges from source to destination file."), out);
-
- fputs(USAGE_SEPARATOR, out);
- fputsln(_(" source source filename"), out);
- fputsln(_(" destination destination filename"), out);
- fputsln(_(" range source_offset:dest_offset:length, all values are in bytes"), out);
- fputsln(_(" if length is set to 0 as much as available will be copied"), out);
- fputsln(_(" when the offset is omitted the last file position is used"), out);
+ fputsln(_("Copy the specified range(s) from source to destination file."), out);
fputs(USAGE_OPTIONS, out);
- fputsln(_(" --ranges, -r filename read range(s) separated by newlines from filename"), out);
- fputsln(_(" --verbose, -v verbose mode"), out);
+ fputsln(_(" -r, --ranges <file> read ranges separated by newlines from this file"), out);
+ fputsln(_(" -v, --verbose verbose mode"), out);
fputs(USAGE_SEPARATOR, out);
- fprintf(out, USAGE_HELP_OPTIONS(16));
+ fprintf(out, USAGE_HELP_OPTIONS(25));
+
+ fputs(USAGE_ARGUMENTS, out);
+ fputsln(_(" <range> is of the form <source_offset>:<destination_offset>:<length>,\n"
+ " with all values in bytes. If <length> is 0, as much data as available\n"
+ " is copied. When an offset is omitted, the last file position is used."), out);
fprintf(out, USAGE_MAN_TAIL("copyfilerange(1)"));
exit(EXIT_SUCCESS);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/2] copyfilerange: (usage) correct the markup and improve the wording
From: Benno Schulenberg @ 2026-03-12 15:52 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Dick Marinus
In-Reply-To: <jg4hhpuwvwuxwkfaobly25qd3rjdlfizcm3jims42zse7m4zue@dqtq3ifmdggn>
[-- Attachment #1.1: Type: text/plain, Size: 934 bytes --]
Op 11-03-2026 om 13:14 schreef Karel Zak:
> On Mon, Mar 09, 2026 at 05:09:02PM +0100, Benno Schulenberg wrote:
>> + fputsln(_("Each <range> is of the form <source_offset>:<destination_offset>:<length>,\n"
>> + "with all values in bytes. If <length> is 0, as much data as available will\n"
>> + "be copied. When an offset is omitted, the last file position is used."), out);
>
> Hmm... for this purpose, we already have the USAGE_ARGUMENTS section
> (usually after the OPTIONS section).
>
> What about:
>
> fputs(USAGE_ARGUMENTS, out);
> fputsln(_(" <range> is of the form <source_offset>:<destination_offset>:<length>,\n"
> " with all values in bytes. If <length> is 0, as much data as available will\n"
> " be copied. When an offset is omitted, the last file position is used."), out);
Yes, that actually looks better. V2 is coming up.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: improvements to terminal-colors.d.5.adoc were undone
From: Benno Schulenberg @ 2026-03-12 15:34 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Mario Blättermann
In-Reply-To: <iio2qnw62rtr5hih47h7m4hyc7glzubqnqonv7n7wjmx2gyljr@lpihqow5qu6n>
[-- Attachment #1.1: Type: text/plain, Size: 2877 bytes --]
Op 10-03-2026 om 19:49 schreef Karel Zak:
> The tables are a better solution than the list for translators. See
> discussion:
> https://github.com/util-linux/util-linux/pull/4089
It would have been nice if the commit message had included the
motivation for the change.
> The list produces things like (po-man/util-linux-man.pot):
>
> #. type: delimited block _
> #: ../lib/terminal-colors.d.5.adoc:115
> msgid ""
> "`` *\\a* Bell (ASCII 7)`` `` *\\b* Backspace (ASCII 8)`` `` *\\e* Escape"
> "(ASCII 27)`` `` *\\f* Form feed (ASCII 12)`` `` *\\n* Newline (ASCII 10)``"
> "`` *\\r* Carriage Return (ASCII 13)`` `` *\\t* Tab (ASCII 9)`` `` *\\v*"
> "Vertical Tab (ASCII 11)`` `` *\\?*{nbsp}{nbsp}{nbsp}Delete (ASCII 127)`` ``"
> "*\\_* Space`` `` *\\\\* Backslash (\\)`` `` *\\^* Caret (^)`` `` *\\\\#*"
> "Hash mark (#)``"
> msgstr ""
Cannot `po4a` be told to put every line of a "delimited block" onto
a separate line, or otherwise into a separate msgid?
> The table is more readable:
>
> #. type: Table
> #: ../lib/terminal-colors.d.5.adoc:131
> #, no-wrap
> msgid ""
> "|0\n"
> "|to restore default color\n"
> "\n"
> "|1\n"
> "|for brighter colors\n"
> "\n"
> [...]
In the msgid, yes. But in the man page... it becomes a monstrosity:
┌───┬──────────────────────────┐
│ │ │
│0 │ to restore default color │
├───┼──────────────────────────┤
│ │ │
│1 │ for brighter colors │
├───┼──────────────────────────┤
│ │ │
│4 │ for underlined text │
├───┼──────────────────────────┤
<snip>
├───┼──────────────────────────┤
│ │ │
│33 │ for yellow (or brown) │
│ │ foreground │
├───┼──────────────────────────┤
<snip>
*Two thirds* of the table are lines and empty space, and only one
third contains information. Plus: the table uses less than half
the available width of the man page, meaning that some descriptions
get unnecessarily wrapped. The whole impression is horrible -- a
typograhically-minded person would be banging his head against the
keyboard in frustration. :( This horrible look was the reason to
restore the list form as it existed before the change to asciidoc.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] lsmem: correct the grammar of an error message
From: Karel Zak @ 2026-03-12 10:18 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Sumanth Korikkar
In-Reply-To: <20260307114308.7517-1-bensberg@telfort.nl>
On Sat, Mar 07, 2026 at 12:43:07PM +0100, Benno Schulenberg wrote:
> sys-utils/lsmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied this one, thanks.
For the second lsmem patch, I'm not sure if it needs an update to
provide more information about online/offline status and
configuration.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] waitpid: consistently write the abbreviation "PID" in all-uppercase
From: Karel Zak @ 2026-03-12 10:14 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Christian Goeschel Ndjomouo
In-Reply-To: <20260309111544.4952-1-bensberg@telfort.nl>
On Mon, Mar 09, 2026 at 12:15:44PM +0100, Benno Schulenberg wrote:
> misc-utils/waitpid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/3] nsenter: (usage) correct the formatting of eight option arguments
From: Karel Zak @ 2026-03-12 10:14 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Xiao Liang
In-Reply-To: <20260308112004.9206-1-bensberg@telfort.nl>
On Sun, Mar 08, 2026 at 12:20:02PM +0100, Benno Schulenberg wrote:
> sys-utils/nsenter.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
Applied all three nsenter patches, thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Sumanth Korikkar @ 2026-03-11 13:24 UTC (permalink / raw)
To: Karel Zak; +Cc: Benno Schulenberg, util-linux
In-Reply-To: <d6fywjkl5vvef3uyshxi477fe6vtnzygb7sjsy5mecs7c546gd@cy73pfohzucq>
On Wed, Mar 11, 2026 at 01:27:03PM +0100, Karel Zak wrote:
> On Mon, Mar 09, 2026 at 01:36:32PM +0100, Sumanth Korikkar wrote:
> > How about the following?
> > Example STATE, CONFIGURED, MEMMAP-ON-MEMORY states:
> > STATE | CONFIGURED | MEMMAP-ON-MEMORY | Description
> > online | yes | yes | Memory block is configured with memmap-on-memory enabled and online.
> > online | yes | no | Memory block is configured with memmap-on-memory disabled and online.
> > offline | yes | yes | Memory block is configured but currently offline.
> > offline | no | yes | Memory block is deconfigured and was previously configured with memmap-on-memory.
> > offline | no | no | Memory block is deconfigured and was not previously configured with memmap-on-memory.
Hi Karel,
> I personally prefer structured information like lists or tables and
> dislike large text blocks ;-)
I chose a table because I felt it would show the state combinations more
clearly. But I understand it does make the text heavier.
> However, in this case, I'm not sure if the description adds anything,
> as it repeats what is obvious from STATE, CONFIGURED, MEMMAP-ON-MEMORY
> columns.
Thanks for the feedback. In that case, we can drop the
table and keep the sentence which was proposed earlier.
> What I find relevant is "previously configured." Maybe add a sentence
> stating that CONFIGURED and MEMMAP-ON-MEMORY for _offline_ blocks show
> the previous setup.
For offline blocks, only the MEMMAP‑ON‑MEMORY value reflects the
previous setup or the initial default. If this value isn’t changed
during the next configuration, it will simply be carried forward and
used again.
An offline but configured block is possible.
chmem -c -b <blockno> -m 1
Thanks & Regards,
Sumanth
^ permalink raw reply
* Re: [PATCH 2/2] lsmem: (man) correct the markup of column names, and improve some grammar
From: Karel Zak @ 2026-03-11 12:27 UTC (permalink / raw)
To: Sumanth Korikkar; +Cc: Benno Schulenberg, util-linux
In-Reply-To: <aa6-0Gx7Q8ZzWozj@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com>
On Mon, Mar 09, 2026 at 01:36:32PM +0100, Sumanth Korikkar wrote:
> How about the following?
> Example STATE, CONFIGURED, MEMMAP-ON-MEMORY states:
> STATE | CONFIGURED | MEMMAP-ON-MEMORY | Description
> online | yes | yes | Memory block is configured with memmap-on-memory enabled and online.
> online | yes | no | Memory block is configured with memmap-on-memory disabled and online.
> offline | yes | yes | Memory block is configured but currently offline.
> offline | no | yes | Memory block is deconfigured and was previously configured with memmap-on-memory.
> offline | no | no | Memory block is deconfigured and was not previously configured with memmap-on-memory.
I personally prefer structured information like lists or tables and
dislike large text blocks ;-)
However, in this case, I'm not sure if the description adds anything,
as it repeats what is obvious from STATE, CONFIGURED, MEMMAP-ON-MEMORY
columns.
What I find relevant is "previously configured." Maybe add a sentence
stating that CONFIGURED and MEMMAP-ON-MEMORY for _offline_ blocks show
the previous setup.
Benno, what do you think?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/2] copyfilerange: (usage) correct the markup and improve the wording
From: Karel Zak @ 2026-03-11 12:14 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, Dick Marinus
In-Reply-To: <20260309160903.15490-1-bensberg@telfort.nl>
On Mon, Mar 09, 2026 at 05:09:02PM +0100, Benno Schulenberg wrote:
> The <source>, <destination>, and <range> arguments are required,
> so do not mark them as optional (with the square brackets).
> Also, trim the redundant lines about the source and destination
> files, improve the explanation for the <range> argument, and
> keep the text within 80 columns.
>
> Furthermore, list the short options first (as is custom), and
> match the indentaion of the -h and -V options to the others.
>
> CC: Dick Marinus <dick@mrns.nl>
> Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
> ---
> misc-utils/copyfilerange.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/misc-utils/copyfilerange.c b/misc-utils/copyfilerange.c
> index 20f0373bd..a72c81cd1 100644
> --- a/misc-utils/copyfilerange.c
> +++ b/misc-utils/copyfilerange.c
> @@ -55,25 +55,23 @@ static void __attribute__((__noreturn__)) usage(void)
> FILE *out = stdout;
> fputs(USAGE_HEADER, out);
> fprintf(out,
> - _(" %1$s [options] [<source>] [<destination>] [<range>...]\n"),
> + _(" %1$s [options] <source> <destination> <range>...\n"),
> program_invocation_short_name);
>
> fputs(USAGE_SEPARATOR, out);
> - fputsln(_("Copy file ranges from source to destination file."), out);
> + fputsln(_("Copy the specified range(s) from source to destination file."), out);
>
> fputs(USAGE_SEPARATOR, out);
> - fputsln(_(" source source filename"), out);
> - fputsln(_(" destination destination filename"), out);
> - fputsln(_(" range source_offset:dest_offset:length, all values are in bytes"), out);
> - fputsln(_(" if length is set to 0 as much as available will be copied"), out);
> - fputsln(_(" when the offset is omitted the last file position is used"), out);
> + fputsln(_("Each <range> is of the form <source_offset>:<destination_offset>:<length>,\n"
> + "with all values in bytes. If <length> is 0, as much data as available will\n"
> + "be copied. When an offset is omitted, the last file position is used."), out);
Hmm... for this purpose, we already have the USAGE_ARGUMENTS section
(usually after the OPTIONS section).
What about:
fputs(USAGE_ARGUMENTS, out);
fputsln(_(" <range> is of the form <source_offset>:<destination_offset>:<length>,\n"
" with all values in bytes. If <length> is 0, as much data as available will\n"
" be copied. When an offset is omitted, the last file position is used."), out);
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox