Packer: v 1.3.5 no longer able to copy resources from symbolic linked directories

[ablundgren]

version 1.3.5
linux (fedora 28) x86

log:
https://gist.github.com/ablundgren/88115ba7beacc18a29a4afca52c943fc

create symbolic link to directory containing resources to be copied onto the host. Run the build and it fails with an lstat error.

[SwampDragons]

What is the last Packer version that this worked for?

[SwampDragons]

I can't reproduce on osx or my ubuntu machine; can you provide a packer template that reproduces?

[ablundgren]

It works on 1.3.4. I will set up a small example.

[ablundgren]

packer-test.tar.gz

inside the packer-test/sample run:
% packer image.json

The issue actually appears to be a copy problem when crossing a symlink that goes over two .. 's .
i.e:
file -> ../../dest/file

[SwampDragons]

Rebuilding v1.3.4 from tags yields a Packer that fails the same way as it is in your logs. Once I downloaded the actual release from our site, I got the successful run, though. That means this has to do with the golang version upgrade we did between 1.3.4 and 1.3.5. go 1.11.4 passes, but go 1.12 fails.

I'll try to figure out what changed and whether we can work around it to preserve the old behavior.

[SwampDragons]

Found the upstream bug: https://github.com/golang/go/issues/30520

The good news is, this has been fixed, merged and has been backported to the 1.12 release branch https://github.com/golang/go/issues/30586

I will make sure we release 1.4.1 with the latest version of golang, but in the meantime, here's a linux build of the master branch with golang 1.12.4. I tested, and it resolves your symlink issue.

packer.zip

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.