Summary: | FreeBSD: cp -a (-P) fails when encountering broken symlinks | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yuta SATOH <nigoro.dev> |
Component: | Eclasses | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | ryao |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
URL: | http://www.freebsd.org/cgi/query-pr.cgi?pr=174489 | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=507626 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 451082 | ||
Bug Blocks: | |||
Attachments: |
Patch from upstream
sample patch for distutils-r1.eclass sample patch for multibuild.eclass sample patch for multibuild.eclass (use GNU's cp version) |
Description
Yuta SATOH
2012-12-15 15:53:44 UTC
(In reply to comment #0) > cp behaves differently on FreeBSD. > Because of it, dev-python/setuptools-0.6.32 will fail to install. Err, -n (--no-clobber) handles that on Linux. That looks like a bug in FreeBSD to me. @ryao, could you help a bit with this one? Based on reading the cp source code, I agree that this seems to be a bug. Inside of copy() in cp.c [1], the dne variable is set to 1 based on a call to stat(2). stat(2) attempts to follow symlinks, and returns -1 when called on the easy_install -> python-exec symlink because python-exec doesn't exist in ${D}. !dne is then passed to copy_link in utils.c [2]. copy_link is supposed to remove the destination if it exists (via unlink), but the bad value in dne causes this to be skipped. Since the destination file is not removed, the call to symlink then fails, producing the "cp: symlink: python-exec: File exists" message. I think this could be fixed by changing the stat(2) to lstat(2) in cp.c. copy_link should probably be changed to obey the "-n" flag (nflag) as well. [1] http://svnweb.freebsd.org/base/head/bin/cp/cp.c?view=markup [2] http://svnweb.freebsd.org/base/head/bin/cp/utils.c?view=markup Thanks for the analysis, Mike. Another thing suggesting that this is a bug is the error message stating the wrong file (link destination). Created attachment 332902 [details, diff]
Patch from upstream
Could any of you BSD-ers test the attached patch to cp?
(In reply to comment #4) > Created attachment 332902 [details, diff] [details, diff] > Patch from upstream > > Could any of you BSD-ers test the attached patch to cp? @BSD, could you please test this patch? The OP is not responsive, we don't have any system to test it and the bug is stalled because of lack of it... Created attachment 335060 [details, diff] sample patch for distutils-r1.eclass (In reply to comment #5) > (In reply to comment #4) > > Created attachment 332902 [details, diff] [details, diff] [details, diff] > > Patch from upstream > > > > Could any of you BSD-ers test the attached patch to cp? > > @BSD, could you please test this patch? The OP is not responsive, we don't > have any system to test it and the bug is stalled because of lack of it... Result of patched cp) # cp -a -l -v -n 1/* 3/ # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. Why copy file will not be displayed ? @bsd, BTW, I don't know the status of Gentoo/*BSD projects other than FreeBSD. Doesn't happen this problem other BSD similarly ? If problem to occur, what about using tar instead of cp. (In reply to comment #6) > Created attachment 335060 [details, diff] [details, diff] > sample patch for distutils-r1.eclass > > (In reply to comment #5) > > (In reply to comment #4) > > > Created attachment 332902 [details, diff] [details, diff] [details, diff] [details, diff] > > > Patch from upstream > > > > > > Could any of you BSD-ers test the attached patch to cp? > > > > @BSD, could you please test this patch? The OP is not responsive, we don't > > have any system to test it and the bug is stalled because of lack of it... > > Result of patched cp) > > # cp -a -l -v -n 1/* 3/ > # cp -a -l -v -n 1/* 3/ > 3/easy_install not overwritten > > I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. > Why copy file will not be displayed ? You mean that '-v' works incorrectly? (In reply to comment #7) > (In reply to comment #6) > > Created attachment 335060 [details, diff] [details, diff] [details, diff] > > sample patch for distutils-r1.eclass > > > > (In reply to comment #5) > > > (In reply to comment #4) > > > > Created attachment 332902 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Patch from upstream > > > > > > > > Could any of you BSD-ers test the attached patch to cp? > > > > > > @BSD, could you please test this patch? The OP is not responsive, we don't > > > have any system to test it and the bug is stalled because of lack of it... > > > > Result of patched cp) > > > > # cp -a -l -v -n 1/* 3/ > > # cp -a -l -v -n 1/* 3/ > > 3/easy_install not overwritten > > > > I think the results of `cp -a -l -v -n 1/* 3/` is incorrect. > > Why copy file will not be displayed ? > > You mean that '-v' works incorrectly? Yes. When the option -n is enabled, the following line is seems to be that it does not displayed. 1/easy_install -> 3/easy_install Actual Results # rm 3/* # cp -a -l -v -n 1/* 3/ # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten Expected Results # rm 3/* # cp -a -l -v -n 1/* 3/ 1/easy_install -> 3/easy_install # cp -a -l -v -n 1/* 3/ 3/easy_install not overwritten FYI, Option -n is disabled results. # cp -a -l -v 1/* 3/ 1/easy_install -> 3/easy_install The general issue has been fixed by using tar; I'll leave this bug for the 'cp' bug however. Created attachment 374808 [details, diff]
sample patch for multibuild.eclass
dev-python/{pyelftools-0.21-r4,setuptools-2.2} install fails on Gentoo/FreeBSD...
* Messages for package dev-python/pyelftools-0.21-r4:
* ERROR: dev-python/pyelftools-0.21-r4::gentoo failed (install phase):
* python3_3: merging image failed.
*
* Call stack:
* ebuild.sh, line 93: Called src_install
* environment, line 3546: Called distutils-r1_src_install
* environment, line 1211: Called _distutils-r1_run_foreach_impl 'distutils-r1_python_install'
* environment, line 233: Called python_parallel_foreach_impl 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 3386: Called multibuild_parallel_foreach_variant '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 2529: Called multibuild_foreach_variant '_multibuild_parallel' '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 2478: Called _multibuild_run '_multibuild_parallel' '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 2476: Called _multibuild_parallel '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 2520: Called _python_multibuild_wrapper 'distutils-r1_run_phase' 'distutils-r1_python_install'
* environment, line 664: Called distutils-r1_run_phase 'distutils-r1_python_install'
* environment, line 1179: Called distutils-r1_python_install
* environment, line 1129: Called multibuild_merge_root '/var/tmp/portage/dev-python/pyelftools-0.21-r4/image//_python3.3' '/var/tmp/portage/dev-python/pyelftools-0.21-r4/image/'
* environment, line 2509: Called die
* The specific snippet of code:
* die "${MULTIBUILD_VARIANT:-(unknown)}: merging image failed.";
*
* If you need support, post the output of `emerge --info '=dev-python/pyelftools-0.21-r4::gentoo'`,
* the complete build log and the output of `emerge -pqv '=dev-python/pyelftools-0.21-r4::gentoo'`.
* The complete build log is located at '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/environment'.
* Working directory: '/var/tmp/portage/dev-python/pyelftools-0.21-r4/work/pyelftools-0.21'
* S: '/var/tmp/portage/dev-python/pyelftools-0.21-r4/work/pyelftools-0.21'
*
* The following package has failed to build or install:
*
* (dev-python/pyelftools-0.21-r4:0/0::gentoo, ebuild scheduled for merge), Log file:
* '/var/tmp/portage/dev-python/pyelftools-0.21-r4/temp/build.log'
*
Created attachment 374810 [details, diff] sample patch for multibuild.eclass (use GNU's cp version) Alternative solution... Add sys-apps/coreutils to DEPEND or @system, use GNU's cp. On FreeBSD, the name of GNU's cp is gcp. # equery f coreutils | grep cp /usr/bin/gcp However, KEYWORDS of coreutils is not enough. (Probably, this problem will also occur on prefix but no KEYWORDS...) http://packages.gentoo.org/package/sys-apps/coreutils?arches=all We no longer use 'cp -aln' so this bug is obsolete. Ok, so it's about plain -a as well... Well, let's make this bug focused purely on weird BSD behavior and not eclasses. Ok then. Merged just the 'cp -r' -> 'cp -R' change. commit 7adffa3687e1abf7ee24b096b8ab2f39a7ee32b9 Author: Michał Górny <mgorny@gentoo.org> Date: Sat Dec 19 08:57:56 2015 multibuild.eclass: _copy_sources(), use 'cp -R' for BSD compat, #568692 Use 'cp -R' for multibuild_copy_sources() as the '-r' option triggers triggers undesired '-L' behavior wrt symbolic links. Fixes: https://bugs.gentoo.org/show_bug.cgi?id=568692 Sorry, closed the wrong bug. *-fbsd is gone. |