From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 1A0B11FF162 for <inbox@lore.proxmox.com>; Mon, 7 Apr 2025 10:01:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B83E337D64; Mon, 7 Apr 2025 10:01:02 +0200 (CEST) Message-ID: <d417d7d1-01c1-4263-9bd4-78519967c0d1@proxmox.com> Date: Mon, 7 Apr 2025 10:00:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Thomas Lamprecht <t.lamprecht@proxmox.com>, Shannon Sterz <s.sterz@proxmox.com> References: <20250312083819.15379-1-s.sterz@proxmox.com> <e5361beb-42ff-4cf2-ae45-225b6387ac6a@proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <e5361beb-42ff-4cf2-ae45-225b6387ac6a@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.037 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] applied: [PATCH pve-storage] dismanagement: account for leading white space in serial number X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 06.04.25 um 21:19 schrieb Thomas Lamprecht: > did a s/dismanagement/disk management/ for the subject on applying this. > > Am 12.03.25 um 09:38 schrieb Shannon Sterz: >> some manufacturer seem to report leading white space in the >> `ID_SERIAL_SHORT` field. the regex failed here, as it just didn't >> match the whitespace at all. >> >> reported on the forum: >> https://forum.proxmox.com/threads/nvme-drive-serial-unknown.163480/#post-754953 >> >> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com> >> --- >> >> not sure this is the ideal fix, but i tried to stay on the more >> conservative side here. alternatively the regex could be: >> >> ^E: ID_SERIAL_SHORT=(.+)$ >> >> but then the whitespace would be considered as part of the serial, not >> sure this is intended or could have negative side effects. > > As serials are often printed on labels it would be really error > prone to include spaces in them. > >> >> src/PVE/Diskmanage.pm | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> > > applied, thanks! What about spaces at the end though, are they already > parsed out and thus allowed? And I suppose we should make the behavior in PBS consistent with this too? There, we get the value via udev_device_get_property_value() via the udev crate. Haven't checked, but I'd be surprised if that wouldn't pass along the value verbatim. OTOH, one could also argue that the correct behavior is that, i.e. be transparent between user and udev. We could also ask upstream if udev considers including the whitespace correct behavior in the first place? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel