You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[release/10.0-preview4] Tar: Adjust the way we write GNU longlink and longpath metadata (#114942)
* Fix 3 GNU longlink and longpath bugs
The Tar entry types Longlink and Longpath, which are exclusive to the GNU format, are metadata entries used to store longer-than-expected link or name strings (respectively). They precede their actual entry, and they are not visible to the user, only the data they hold is visible.
Most of the regular header metadata in this metadata entries is not relevant, but we need to make sure it is well formed so other tools can read them properly.
There are 3 fields that were not getting their values stored as expected by other tools:
- The mtime, ctime and atime fields need to be set to the Unix Epoch so it shows up as zeros (0x30) by default. We were storing them as null (0x0) characters instead. For consistency, if a regular entry happens to get its mtime set to the Epoch, it should also be shown as zeros (0x30).
- The uid, gid, uname and gname fields were not being set. These fields aren't really important in a metadata entry, but other tools set this to the default value (uid=gid=0 and uname=gname=root). Based on the fact that 'a value' is preferred for these fields, we can set them to the same value that the real entry has (not root).
- The long text value (either link or name) should be null terminated, and this extra character should be counted in the size of the longpath. The library libdpkg, used by the dpkg-deb tool in Debian, expects a null terminator in longlink and longpath data starting in Debian 12. Without the terminator, these entries are considered malformed.
---------
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
Debug.Assert(longLinkHeader._dataStream!=null&&longLinkHeader._dataStream.CanSeek);// We generate the long metadata data stream, should always be seekable
Debug.Assert(longPathHeader._dataStream!=null&&longPathHeader._dataStream.CanSeek);// We generate the long metadata data stream, should always be seekable
Debug.Assert(longLinkHeader._dataStream!=null&&longLinkHeader._dataStream.CanSeek);// We generate the long metadata data stream, should always be seekable
Debug.Assert(longPathHeader._dataStream!=null&&longPathHeader._dataStream.CanSeek);// We generate the long metadata data stream, should always be seekable
0 commit comments