Tar: string fields are truncated when they don't fit but we should throw instead

[jozkee]

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.

cc @carlossanlop

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This table shows each field 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	32
GroupName	N/A	32	32	32

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, Pax, and Gnu.

For Name and LinkName on Pax and Gnu is acceptable to truncate as those formats haveare capable of storing those fields without limit restriction.

I also checked how GNU Tar handles these cases and it aligns with what I just described.

cc @carlossanlop

Author:	Jozkee
Assignees:	-
Labels:	area-System.IO
Milestone:	-

[danmoseley]

If we changed this in 8.0 it would be a breaking change (possibly an acceptable one but nevertheless breaking)

[jozkee]

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.

	GNU Ustar	BSD Ustar	GNU Pax	BSD Pax	GNU Gnu	BSD Gnu
Name 101 doesn't fit	Throws	Throw	Truncate	Truncate	Truncate	NA
Name 101 and prefix 156 desn't fit	Throws - file name is too long (max 256)	Pathname too long	Truncates and writes all into name		Truncates and writes all into name	NA
Prefix 1 fits, name 101 doesn't	Throws	Throws	Truncates and writes all into name	Truncates name but writes prefix	Truncates and writes all into name	NA
Name 100 and Prefix 1 fit	Writes into name  and prefix	Writes into name  and prefix	Truncates and writes all into name	Writes into name  and prefix	Truncates and writes all into name	NA
Name 100 and Prefix 155 fit	Writes into name  and prefix	Writes into name  and prefix	Truncates and writes all into name	Writes into name  and prefix	Truncates and writes all into name	NA

[jozkee]

This is the guideline for storing pathnames in ustar format:

If the pathname is too long to fit in the 100 bytes provided by the standard format, it can be split at any / character with the first portion going into the prefix field.

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.