GitLab

This is a reland of 6a008993, which was reverted in 235d842a.
(Thus, this is a revert of that revert.)

Since the last attempt, the structure of the keystone_registration
bundle_data rule in third_party/googlemac (via src-internal DEPS) has
changed to avoid the dangling symbolic link problem previously
encountered.

The description from 6a008993:

The copy_bundle_data tool is implemented in terms of pax for directories
and ln hard links for files. The pax command does preserve symbolic
links within the tree that is being copied. But with the way that pax is
invoked by the tool, cd-ing into the source, if the source is itself
a symbolic link to a directory, the tree will be logically copied rather
than just as a symbolic link.

A similar issue exists with the non-directory symbolic link source case,
where a hard link will be produced instead of a symbolic link.

Fix both of these cases by specifically testing if the source is a
symbolic link and then re-creating it if so.

Bug: 955936
Change-Id: Ia13ddf743603e98337c3523e9101e7627e1c31d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1637673Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#665203}