proposal: archive/tar: AddFS: add support for symlinks outside subdirectory

[dmivankov]

Proposal Details

1.25 AddFS will support resolving symlinks to their target contents,
but it doesn't work for symlinks pointing to locations outside of added fs

func (tw *Writer) AddFS(fsys fs.FS) error {
	return fs.WalkDir(fsys, ".", func(name string, d fs.DirEntry, err error) error {

Here whole fs is traversed, so fs should be the whole archive contents.
Despite fs not being chroot symlink resolution to targets outside fs doesn't work.

Context

Bazel and rules_oci use symlinks for build actions environment setup, there an OCI image layout can be in one directory but some of base layer blobs be symlink to locations in another directory. If Go archive/tar is used to archive that image AddFS won't be able to package it and fail

Proposal

Replace hardcoded "." walkdir start with a subdirectory string parameter, then it will be possible to archive
symlinks pointing to outside of archive directory, by calling AddFS(os.DirFS("/"), absolutePath) or say AddFS(pwd, subdirectory) when all dependencies are within pwd but archive only needs to contain subdirectory layout

[seankhliao]

I don't think this can do what you want. Tar as a format preserves symlinks.
You generally don't want archive/tar to resolve all your symlinks for you, or you may end up with a very bloated archive.
I think for bazel / rules_oci you will always need some custom code to delimit the level of symlink resolution.

[dmivankov]

Right, I misread what 1.25 will do, kkpan11@f7b8dd9#diff-e2a308afe954773e734c2e511a3247ade311346eacab2579d5b408534752d795L418 will still archive symlink as symlink.
Then the feature request could be to expose helper methods to simplify implementing symlink resolution on client side, or a new explicit flag (getting closer in feature set to gnutar/bsdtar, may be out of scope for go std library), I'll make another feature request if it still would look reasonable for standard library

[seankhliao]

I think it'd be out of scope, a wrapper io/fs.FS shouldn't be too difficult to implement.