Skip to content

tar: add support for GNU longnames/PAX tar extension entry

Christian Marangi requested to merge Ansuel/apk-tools:scriptdb-longnames into master

There is currently a fundamental problem with how tar are handled insternally for scriptdb usage.

We totally lack any support and handling for filename in scriptdb that are longer than 99char. This cause the filename to be cut and have situation with file ending with:

  • kernel-6.6.30~01f651a1bd5c5592d7cf5a98209bdce4-r1.X121290490411c8c2cf47e3
  • kernel-6.6.30~01f651a1bd5c5592d7cf5a98209bdce4-r1.X121290490411c8c2cf47e308d95f12d65d011a391.post-instal
  • kernel-6.6.30~01f651a1bd5c5592d7cf5a98209bdce4-r1.X121290490411c8c2cf47e308d95f12d65d011a391.post-i
  • kernel-6.6.30~01f651a1bd5c5592d7cf5a98209bdce4-r1.X121290490411c8c2cf47e308d95f12d65

This is caused by the fact that POSIX ustar support up to 99char. The prefix value can only be used to path but can't be used for filename hence that is not a valuable solution.

To fix this introduce support to apk_tar_write_entry for GNU longnames extension header. This is already supported by apk_tar_parse but we couldn't actually add the special header.

With this fix long filename are correctly handled and the cut problem is solved.

This can be controlled by the new option "tar_longnames_handling" and can be disabled by setting this option to 'none'.

Add support for tar PAX extension header.

This is the POSIX way to support longnames for filenames. The implementation is a bit more complex than GNU longnames but more solid.

Since we prefer to follow POSIX, this is enabled by default instead of GNU_LONGNAMES implementation.

We still hardcode filnemaes to a max value of 255 to handle systems that doesn't support longer path. This value can easly increased to higher values if needed and currently with no change in how the PAX header logic works it can be increased to a value of 988 char.

Signed-off-by: Christian Marangi ansuelsmth@gmail.com

Merge request reports