From unknown Wed Jun 18 00:27:09 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#54835 <54835@debbugs.gnu.org> To: bug#54835 <54835@debbugs.gnu.org> Subject: Status: Inconsistent interpretation of end specifications Reply-To: bug#54835 <54835@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:27:09 +0000 retitle 54835 Inconsistent interpretation of end specifications reassign 54835 parted submitter 54835 Joshua Kr=C3=A4mer severity 54835 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 10 08:23:22 2022 Received: (at submit) by debbugs.gnu.org; 10 Apr 2022 12:23:22 +0000 Received: from localhost ([127.0.0.1]:39647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndWbB-00058k-Ik for submit@debbugs.gnu.org; Sun, 10 Apr 2022 08:23:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:44584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndVOy-0002sP-F5 for submit@debbugs.gnu.org; Sun, 10 Apr 2022 07:06:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndVOy-0002N7-8n for bug-parted@gnu.org; Sun, 10 Apr 2022 07:06:40 -0400 Received: from sender4-of-o51.zoho.com ([136.143.188.51]:21145) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndVOw-0003pf-Fa for bug-parted@gnu.org; Sun, 10 Apr 2022 07:06:39 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1649588793; cv=none; d=zohomail.com; s=zohoarc; b=Ybpf4q88U9S17he5eAEi8ndQwUBTOUal7RqcX7Hyf0LbHDhAMXAxP0uBiDr29FYk7UStCLIeeG1yMjq5o/+foCCqBeJcLZuqtLIjY06TYTzbfHS+gQ/QM9cScQemijz5bnhx25lkHDKyXjpblE0QdxQb7mjRqHWnHg7zL+dM+8I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1649588793; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To; bh=SRFKjoiYdGVJPtyyTQCCAnz+bgtlf0tfjKvU3IkZOlc=; b=H1RJJv8MAEmkOR7VM96c6AV7eqYcSdxANe7TxktIbURdS7ojxbHz6FkVM3vCnQP2BZF2yEsVIBIdcHTb+bTcGJWUpzq2w5gY48EBwPS4F9p/9rFKBTr0pZnByW6l2pS6+Mg++auzVVy4jzGJiez3Ax+i7O8VhALPM1XMfFxR3H4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=kraemer.link; spf=pass smtp.mailfrom=joshua@kraemer.link; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1649588793; s=zoho; d=kraemer.link; i=joshua@kraemer.link; h=MIME-Version:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=SRFKjoiYdGVJPtyyTQCCAnz+bgtlf0tfjKvU3IkZOlc=; b=ZFMPKu4KwMqpPwfTraFXmuGCknKV3Ysvo0IUvFQhm/q8JHBSYbqxEJ0kqrj1/cZF G0Hwc2aeYmUd6BjQIai2pYAQjqhg0rgBJqgEjnUfa414exwjKtw5rcFCwC+LoR1Tgi9 2Q6A+ld6K/uIuKC98x5N8K+HeqxcoIwIbhh7xG6M= Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by mx.zohomail.com with SMTPS id 1649588792453841.4364256377747; Sun, 10 Apr 2022 04:06:32 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id g18so503555ejc.10 for ; Sun, 10 Apr 2022 04:06:31 -0700 (PDT) X-Gm-Message-State: AOAM533Q2Zyh6EFwRTp49F8A6G0nwFCSEXX3HO/fM5MBPkWhuOMwr6Bf DxoEcjOiv2mI9Cu3VKLdndDhDo5G7EcEFPmleIc= X-Google-Smtp-Source: ABdhPJz8pSuXayPcHlU2jxku6oHuajAWHpG8y28bFVzTZwpyiKyZ99etdiDcvII/BslMGcWsBqV2uE+SaY9A+U2eSjk= X-Received: by 2002:a17:907:d1e:b0:6e1:3aa5:8e5 with SMTP id gn30-20020a1709070d1e00b006e13aa508e5mr25483919ejc.324.1649588790643; Sun, 10 Apr 2022 04:06:30 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Joshua_Kr=C3=A4mer?= Date: Sun, 10 Apr 2022 13:47:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Inconsistent interpretation of end specifications To: bug-parted@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.51; envelope-from=joshua@kraemer.link; helo=sender4-of-o51.zoho.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 10 Apr 2022 08:23:20 -0400 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 (--) Dear parted developers, the mkpart end specification seems to be interpreted differently depending on the given unit. If the end location is given in s, B or KiB, it seems to be interpreted as the offset of the partition's last sector: | $ parted test.img | WARNING: You are not superuser. Watch out for permissions. | GNU Parted 3.4 | Using /home/joshua/parted/test.img | Welcome to GNU Parted! Type 'help' to view a list of commands. | (parted) mkpart test 2048s 4096s | (parted) unit s | (parted) print | Model: (file) | Disk /home/joshua/parted/test.img: 6144s | Sector size (logical/physical): 512B/512B | Partition Table: gpt | Disk Flags: | | Number Start End Size File system Name Flags | 1 2048s 4096s 2049s test "mkpart test 1048576B 2097152B" and "mkpart test 1024KiB 2048KiB" give the same result. However, if the end is specified in MiB, it seems to be interpreted as the offset of the first sector after the partition's end: | (parted) mkpart test 1MiB 2MiB | (parted) print | Model: (file) | Disk /home/joshua/parted/test.img: 6144s | Sector size (logical/physical): 512B/512B | Partition Table: gpt | Disk Flags: | | Number Start End Size File system Name Flags | 1 2048s 4095s 2048s test The meaning of the end specification with the print command seems to be different as well. I think it represents the offset of the first sector after the partition's end minus 1 unit (rounded): | (parted) mkpart test 1048576B 2097152B | (parted) unit B | (parted) print | Model: (file) | Disk /home/joshua/parted/test.img: 3145728B | Sector size (logical/physical): 512B/512B | Partition Table: gpt | Disk Flags: | | Number Start End Size File system Name Flags | 1 1048576B 2097663B 1049088B test If there is a reason for these inconsistencies, I think they should be clearly described in the documentation. Thanks for your work and kind regards, Joshua Kr=C3=A4mer