Repository navigation
Tar: string fields are truncated when they don't fit but we should throw instead #75921
Description
This table shows each field max allowed length, in bytes, according to which format you choose:
| V7 | Ustar | Gnu | Pax | |
|---|---|---|---|---|
| Name | 100 | 256 | Unlimited | Unlimited |
| LinkName | 100 | 100 | Unlimited | Unlimited |
| UserName | N/A | 32 | 32 | Unlimited |
| GroupName | N/A | 32 | 32 | Unlimited |
Our current behavior using TarWriter.WriteEntry is to truncate fields when a string larger-than-the-limit is passed, but I think this is wrong since users may not be aware of such behavior.
I think we should instead throw when a field is unable to fit in the archive entry and there's no other way to preserve it.
That last bit is only true for a subset of the table, i.e:
- Name and LinkName on V7 and Ustar.
- UserName and GroupName on Ustar and Gnu.
For Name and LinkName on Pax and Gnu is acceptable to truncate as those formats are capable of storing those fields without limit restriction (although, they still populate the legacy fields).
I also checked how GNU Tar handles these cases and it aligns with what I just described.
Activity
danmoseley commentedon Sep 21, 2022
If we changed this in 8.0 it would be a breaking change (possibly an acceptable one but nevertheless breaking)
jozkee commentedon Sep 22, 2022
FWIW I collected a couple of cases with BSD Tar in Windows and GNU Tar in Ubuntu:
GNU Tar doesn't care for the legacy fields on gnu or pax format (it always just writes all it can into name and truncates the rest), only cares on ustar format, which makes sense since that's the only capability that format has.
BSD Tar does try to write something in the legacy fields even though values won't fit.
jozkee commentedon Sep 22, 2022
This is the guideline for storing pathnames in ustar format:
My suggested approach would be to do as GNU Tar and only run the "split logic" for ustar, for gnu and pax, we should be fine by just writing a truncated version of the path into name.