From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 0CD971FF141 for ; Fri, 13 Feb 2026 10:22:32 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 06E3931763; Fri, 13 Feb 2026 10:23:19 +0100 (CET) Date: Fri, 13 Feb 2026 10:22:37 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= Subject: applied: [PATCH proxmox-backup] fix #7303: tape: handle NUL bytes in SCSI strings better To: Dominik Csapak , pbs-devel@lists.proxmox.com References: <20260211145947.645587-1-d.csapak@proxmox.com> <1770908450.3jphpww7do.astroid@yuna.none> <67209c23-4945-46f9-bd18-847652b2452d@proxmox.com> In-Reply-To: <67209c23-4945-46f9-bd18-847652b2452d@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1770971489.nfmct3x39f.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770974557594 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.047 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: SCYSUXN5P32I5EY7A3BYFNCSK4QPUKS3 X-Message-ID-Hash: SCYSUXN5P32I5EY7A3BYFNCSK4QPUKS3 X-MailFrom: f.gruenbichler@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On February 12, 2026 4:29 pm, Dominik Csapak wrote: >=20 >=20 > On 2/12/26 4:13 PM, Fabian Gr=C3=BCnbichler wrote: >> On February 11, 2026 3:59 pm, Dominik Csapak wrote: >>> When dealing with ASCII fields in answers from drives and changers, we >>> assumed that the data is simply ascii characters padded by spaces, with >>> potentially a NUL byte at the end. This is indicated for example by the >>> IBM library documentation about the Primary Volume Tag Information[0]: >>> >>> ``` >>> This is a 36 byte ASCII field that contains the cartridge bar code >>> label, left-adjusted and padded on the right with blanks. >>> ``` >>=20 >> doesn't this clash with the trimming below (before and after this >> patch), which will remove whitespace from both start and end? >=20 > well, yes, but if the label is "invalid", there is probably something > else wrong going on, so it shouldn't make much difference. >=20 > i can of course change it to 'trim_end' >=20 >>=20 >>> Some changers may reverse that though, and have a NUL terminated string >>> followed by space padding (e.g. "FOO\0 "). >>=20 >> what about "FOO\0BAR" ? this would now be truncated to "FOO" as well, >> whereas before it was treated as "FOOBAR"? >=20 > no, before it would be treated as 'FOO\0BAR' (since trim only removes it > from beginning and end, not in the middle). right, printing the str will omit the \0, but it is actually preserved by from_utf8_lossy :) > I sadly have no evidence this ever occurs, but seeing the issue in the > bug, my assumption is that the hardware simply overwrites the buffer > with it's internal string representation which might be NUL terminated. >=20 > in that case i can imagine a codepath not prefilling the buffer with > spaces, leading to e.g. first writing: >=20 > 'FOOBAR\0' >=20 > and afterwards >=20 > 'FOO\0' >=20 > which would lead to 'FOO\0AR\0'. in this case we should only use 'FOO'.. ack, I guess it makes sense (as much as things can make sense here ;)) Applied, thanks! [1/1] fix #7303: tape: handle NUL bytes in SCSI strings better commit: baa2077c4b867d686423c6b22be5cb2ee12cad7d Best regards, --=20 Fabian Gr=C3=BCnbichler