From unknown Fri Jun 20 07:29:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#61582 <61582@debbugs.gnu.org> To: bug#61582 <61582@debbugs.gnu.org> Subject: Status: Different behaviour for "mkpart" command while using "kiB" and "KiB" units (case sensitivity) Reply-To: bug#61582 <61582@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:29:20 +0000 retitle 61582 Different behaviour for "mkpart" command while using "kiB" an= d "KiB" units (case sensitivity) reassign 61582 parted submitter 61582 Pavel Iatchenii severity 61582 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 17 12:16:54 2023 Received: (at submit) by debbugs.gnu.org; 17 Feb 2023 17:16:54 +0000 Received: from localhost ([127.0.0.1]:41469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT4Lt-0008VX-TK for submit@debbugs.gnu.org; Fri, 17 Feb 2023 12:16:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:59050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT4G0-0008Il-OU for submit@debbugs.gnu.org; Fri, 17 Feb 2023 12:10:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT4Fz-0007Cc-WF for bug-parted@gnu.org; Fri, 17 Feb 2023 12:10:48 -0500 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pT4Fx-0002Q5-Qx for bug-parted@gnu.org; Fri, 17 Feb 2023 12:10:47 -0500 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-171872a792fso1806078fac.3 for ; Fri, 17 Feb 2023 09:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CPXIfFqfhgs5GlCFo0jv+zmbq7ZhCBJ6p/zJ5iEuKY4=; b=PhSq1QCPb8DA0gQQhp13jvNn1KytiKvrvTydLVFFvDlJOX4sdnROQyvd7PY0KTlUx8 fwec5xua+gSTYRPsM6AmwMHCoDzOLAnAusodqh8ibv8Hmpf5gWPkZRLRQ83P/IThUvh/ /BJ4TO0DKun2/8XM1VSg+yv3eLPmJAgtPbPiQmCHPUtUSgOPICm86ebTOq0cxVfGrFCc eIQ2+WD+ke3uFUoFmICoAS3qeBpb1tGYjG4UV9jh7WByt9dWY9hWNSLaqdHjE/VA9RHn AG52RKOZquoc3m08tj9GIazUIBCxH16yz/ODykXLvo7En6Un460UIvfyeoFYevsl39+0 6rwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CPXIfFqfhgs5GlCFo0jv+zmbq7ZhCBJ6p/zJ5iEuKY4=; b=giaLOkZTl4sFPtO6LWMFCgQJuaguS9gh4C4PXUI1A1o2U5ldtM6hvg2NhCmg7U/4Tt 3ZaWkQSuiHzilgMNFG9MnnTdBcUBZcL9aWPkxsAb+VdiUu1upn+hkxSocW5UWJ0ZiX5m 6HXjTNUhTDGiKNt85MUtZuvh+fKSXW4Tn1sWfFimmuyc4OLzHRmDKhc8cz8SJOnXHlLB 8vDHSc8rSlWHeshJfJ2UWdtMp3DSdFcPtlmVf8ViCVyt0gK4vuX2qwqHSdd/9+EkXxO6 WJohHVpCO0+HjcOKJ0PV6xA5qT/aFMNQzii/XrCMYSBPYXzte+Xh+sIhbK5CFrsnpuYt gt4A== X-Gm-Message-State: AO0yUKUhNf49a5GoZfAZ8vN+9/hjrybdqsLT4oQFN5sOmdDdWOrHaLwm 5kiaav2FQqgX/O9fP2mxNGWQCZRcK53u136Idu2NRUgMECE= X-Google-Smtp-Source: AK7set8sgdJjOM1Qh8qAWb/lQuux5mxVrOpTn3jfatQvKbk4rqygjwvEiE2yhl/Er5z96SHlRemlJMTocjD3QvcpktY= X-Received: by 2002:a05:6870:969e:b0:16e:8d0a:c6d6 with SMTP id o30-20020a056870969e00b0016e8d0ac6d6mr295099oaq.185.1676653842803; Fri, 17 Feb 2023 09:10:42 -0800 (PST) MIME-Version: 1.0 From: Pavel Iatchenii Date: Fri, 17 Feb 2023 17:10:31 +0000 Message-ID: Subject: Different behaviour for "mkpart" command while using "kiB" and "KiB" units (case sensitivity) To: bug-parted@gnu.org Content-Type: multipart/alternative; boundary="000000000000b6319a05f4e86442" Received-SPF: pass client-ip=2001:4860:4864:20::30; envelope-from=paveliatchenii@gmail.com; helo=mail-oa1-x30.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 17 Feb 2023 12:16:53 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000b6319a05f4e86442 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Introduction When you open man page or gnu documentat= ion, you may refer to "unit" command and think that "KiB" is a correct interpretation of, whatever its name, 1024 bytes. And it actually works for using this command as well as creating a single partition with "mkpart" command. Then, there is a BIG one: you can=E2=80=99t create adjacent partit= ions while encountering a weird error: *parted -s /dev/nvme1n1 mkpart primary 128KiB 28692352KiB mkpart primary 28692352KiB 29216640KiB* *Error: You requested a partition from 29.4GB to 29.9GB (sectors 7173088..7304160).* *The closest location we can manage is 29.4GB to 29.9GB (sectors 7173089..7304160).* However, if you proceed with "unit" command as in documentation and keep the case of "KiB", then partitions are created successfully: *parted -s /dev/nvme1n1 unit KiB mkpart primary 128 28692352 mkpart primary 28692352 29216640* Where could be the catch? 1. The code of the above-mentioned "unit" command contains a static constant array of units. It looks like this and has "kiB" with lower cas= e =E2=80=9Ck=E2=80=9D, though further down checks names without case sensi= tivity. *static const char* unit_names[] =3D {* * "s",* * "B",* * "kB",* * "MB",* * "GB",* * "TB",* * "compact",* * "cyl",* * "chs",* * "%",* * "kiB",* * "MiB",* * "GiB",* * "TiB"* *};* 1. There is adjustment to be called whenever the partition is created or resized. It looks like this and also checks for "kiB", though with case sensitivity this time. */* Return true, if str ends with [kMGTPEZY]iB, i.e. IEC units. */* *static bool* *_string_ends_with_iec_unit(const char *str)* *{* * /* 3 characters for the IEC unit and at least 1 digit */* * if (!str || strlen(str) < 4)* * return false;* * char const *p =3D str + strlen(str) - 3;* * return strchr ("kMGTPEZY", *p) && c_strcasecmp (p+1, "iB") =3D=3D = 0;* *}* */* If the selected unit is one of kiB, MiB, GiB or TiB and the partition is not* * * only 1 sector long, then adjust the end so that it is one sector before the* * * given position. Also adjust range_end accordingly. Thus next partition can* * * start immediately after this one.* * ** * * To be called after end sector is read from the user.* * ** * * https://lists.gnu.org/archive/html/bug-parted/2011-10/msg00009.html * * */* *static void* *_adjust_end_if_iec (PedSector* start, PedSector* end,* * PedGeometry* range_end, char* end_input)* *{* * ...* * if (_string_ends_with_iec_unit(end_input) || ...) {* * *end -=3D 1;* * range_end->start -=3D 1;* * range_end->end -=3D 1;* * }* *}* Suggestion Even though units are parsed case-insensitively in most cases, it may be crucial in other cases and lead to the original issue. As such, whether this is a following ICE standard or archaeology, the documentation of "parted" utility could clarify this point and eliminate such problems in the future. Alternatively, both catches could be consistent with each other and treat case sensitivity in the same manner, according to documentation. --000000000000b6319a05f4e86442 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= ntroduction

When you open=C2=A0ma= n=C2=A0page or=C2=A0gnu=C2=A0= documentation, you may refer to "unit" command and think that &qu= ot;KiB" is a correct interpretation of, whatever its name, 1024 bytes.= And it actually works for using this command as well as creating a single = partition with "mkpart" command. Then, there is a BIG one: you ca= n=E2=80=99t create adjacent partitions while encountering a weird error:


=
parted -s /dev/nvme1n1 mkpart primary 128KiB 286923= 52KiB mkpart primary 28692352KiB 29216640KiB
Error: You requested a partition from 29.4G= B to 29.9GB (sectors 7173088..7304160).
The closest location we= can manage is 29.4GB to 29.9GB (sectors 7173089..7304160).

However, if you proceed w= ith "unit" command as in documentation and keep the case of "= ;KiB", then partitions are created successfully:

parted -s /dev/nvme1n1=C2=A0unit= KiB mkpart primary 128 28692352 mkpart primary 28692352 29216640

<= h2 style=3D"color:rgb(24,90,189);font-family:"Calibri Light";font= -size:13pt;margin-left:2pt">Where could be the c= atch?
  1. The code of the ab= ove-mentioned "unit" command contains a static constant array of = units. It looks like this and has "kiB" with lower case =E2=80=9C= k=E2=80=9D, though further down checks names without case sensitivity.
    <= /span>
static const char* unit_names[] =3D {
=C2=A0 =C2=A0 "s",
=
=C2=A0 =C2=A0 &q= uot;B",
=C2=A0 =C2=A0 "kB",
=C2=A0 =C2=A0 "MB",
=C2=A0 =C2=A0 "GB&= quot;,
= =C2=A0 =C2=A0 "TB",
=C2=A0 =C2=A0 "compact",
=C2=A0 =C2=A0 "cyl&= quot;,
= =C2=A0 =C2=A0 "chs",
=C2=A0 =C2=A0 "%",
=C2=A0 =C2=A0 "kiB"= ,
=C2= =A0 =C2=A0 "MiB",
=C2=A0 =C2=A0 "GiB",
=C2=A0 =C2=A0 "TiB"<= /i>
};<= /div>

  1. There is adjustment to be ca= lled whenever the partition is created or resized. It looks like this and a= lso checks for "kiB", though with case sensitivity this time.
    =
/* Return true, if str ends with [kMGTPEZY]iB, i.e. IEC unit= s. =C2=A0*/
s= tatic bool
_string_ends_with_iec_unit(const char *str)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 3 charac= ters for the IEC unit and at least 1 digit */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!str= || strlen(str) < 4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r= eturn false;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 char const *p =3D str + strlen(str) - 3;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 return strchr ("kMGTPEZY", *p) && c_= strcasecmp (p+1, "iB") =3D=3D 0;
}
/* If the= selected unit is one of kiB, MiB, GiB or TiB and the partition is not<= /div>
=C2=A0* onl= y 1 sector long, then adjust the end so that it is one sector before the
=C2=A0* g= iven position. Also adjust range_end accordingly. Thus next partition can
=C2=A0* = start immediately after this one.
=C2=A0*
=C2=A0* To be called after end sector is read f= rom the user.
=C2=A0*
=C2=A0* https://lists.gnu.org/archive/html/bug-parted/2011-10/= msg00009.html
=C2=A0*/
static void
_adjust_end_if_iec (PedSector* start, PedSector* end,=
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PedGeometry* ra= nge_end, char* end_input)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (_str= ing_ends_with_iec_unit(end_input) || ...) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 *end -=3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 range_end->start -=3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 range_end->end -=3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}


Suggest= ion

Even though units are pars= ed case-insensitively in most cases, it may be crucial in other cases and l= ead to the original issue. As such, whether this is a following ICE standar= d or archaeology, the documentation of "parted" utility could cla= rify this point and eliminate such problems in the future. Alternatively, b= oth catches could be consistent with each other and treat case sensitivity = in the same manner, according to documentation.
--000000000000b6319a05f4e86442--