applied: [PATCH proxmox-backup] fix #7303: tape: handle NUL bytes in SCSI strings better

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On February 12, 2026 4:29 pm, Dominik Csapak wrote:
> 
> 
> On 2/12/26 4:13 PM, Fabian Grünbichler 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.
>>> ```
>> 
>> doesn't this clash with the trimming below (before and after this
>> patch), which will remove whitespace from both start and end?
> 
> well, yes, but if the label is "invalid", there is probably something
> else wrong going on, so it shouldn't make much difference.
> 
> i can of course change it to 'trim_end'
> 
>> 
>>> Some changers may reverse that though, and have a NUL terminated string
>>> followed by space padding (e.g. "FOO\0 ").
>> 
>> what about "FOO\0BAR" ? this would now be truncated to "FOO" as well,
>> whereas before it was treated as "FOOBAR"?
> 
> 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.
> 
> in that case i can imagine a codepath not prefilling the buffer with
> spaces, leading to e.g. first writing:
> 
> 'FOOBAR\0'
> 
> and afterwards
> 
> 'FOO\0'
> 
> 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,
-- 
Fabian Grünbichler <f.gruenbichler@proxmox.com>