[Mac] Preserve symbolic links in the copy_bundle_data tool
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}
Showing
Please register or sign in to comment