https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030
--- Comment #17 from Warner Losh <i...@freebsd.org> ---
(In reply to Martin Birgmeier from comment #16)
So we could use tar, with the following super ugly (and likely not very
portable) formulation:
diff --git a/Makefile.inc1 b/Makefile.inc1
index f47b9f66b69e..cc2bdb315a58 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -2584,6 +2584,7 @@ _bootstrap_tools_links+=${_links:S/,/ /g}
# the host version is known to be compatible into ${WORLDTMP}/legacy
# We do this before building any of the bootstrap tools in case they depend on
# the presence of any of the links (e.g. as m4/lex/awk)
+# Use tar because it ignores flags, which we don't want to copy
${_bt}-links: .PHONY
.for _tool in ${_bootstrap_tools_links}
@@ -2593,7 +2594,7 @@ ${_bt}-link-${_tool}: .PHONY
if [ ! -e "$${source_path}" ] ; then \
echo "Cannot find host tool '${_tool}'"; false; \
fi; \
- cp -pf "$${source_path}" "${WORLDTMP}/legacy/bin/${_tool}"
+ tar -cf - --absolute-paths "$${source_path" | tar -C
"${WORLDTMP}/legacy/bin/" -f - -s '=.*/==g'
${_bt}-links: ${_bt}-link-${_tool}
.endfor
But that kinda argues for the cmp route, though we'd need to modify the logic a
bit as well...
I'm surprised the copies in ZFS has this set... But reading the man page, we
see in chflags(2):
For instance, ZFS tracks changes to files and will set this bit when a file is
updated.
which is, imho, decidedly unhelpful.... But that explains how it got set and
the scope of the problem... And I can confirm that my ZFS root machines (which
I hadn't checked) do, indeed, have this set. That argues, imho, that we should
mask this bit in cp, but that's a bigger fight....
I think I need to figure out how to recreate the reason I added -p in the first
place...
--
You are receiving this mail because:
You are the assignee for the bug.
