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