tree 183b4ef898bb22628e05c069bdc317eb709b7cc5
parent 1df56f2932a8b3fc509ba848cd4bfb141a1aedd1
author Mark Mentovai <mark@chromium.org> 1559329608 +0000
committer Commit Bot <commit-bot@chromium.org> 1559329608 +0000

[Mac] Preserve symbolic links in the copy_bundle_data tool

This is a reland of 6a008993a2e5, which was reverted in 235d842aa70a.
(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 6a008993a2e5:

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/+/1637673
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#665203}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 28c84c16d28cba67c4ec61997632f71583453d22