[Bug 275030] buildworld fails if obj dir is NFS-mounted [patch]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275030

--- Comment #17 from Warner Losh <imp@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.