[Bug 235438] cp -R command not working properly
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 24 Apr 2022 13:30:14 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235438
--- Comment #4 from commit-hook@FreeBSD.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b57954717ddfe52be9e18591d302c61e50db0aa6
commit b57954717ddfe52be9e18591d302c61e50db0aa6
Author: Kyle Evans <kevans@FreeBSD.org>
AuthorDate: 2022-01-27 18:02:17 +0000
Commit: Kyle Evans <kevans@FreeBSD.org>
CommitDate: 2022-04-24 03:48:56 +0000
cp: fix some cases with infinite recursion
As noted in the PR, cp -R has some surprising behavior. Typically, when
you `cp -R foo bar` where both foo and bar exist, foo is cleanly copied
to foo/bar. When you `cp -R foo foo` (where foo clearly exists), cp(1)
goes a little off the rails as it creates foo/foo, then discovers that
and creates foo/foo/foo, so on and so forth, until it eventually fails.
POSIX doesn't seem to disallow this behavior, but it isn't very useful.
GNU cp(1) will detect the recursion and squash it, but emit a message in
the process that it has done so.
This change seemingly follows the GNU behavior, but it currently doesn't
warn about the situation -- the author feels that the final product is
about what one might expect from doing this and thus, doesn't need a
warning. The author doesn't feel strongly about this.
PR: 235438
Reviewed by: bapt
Sponsored by: Klara, Inc.
(cherry picked from commit 848263aad129c8f9de75b58a5ab9a010611b75ac)
bin/cp/cp.c | 75 +++++++++++++++++++++++++++++++++++++++++++----
bin/cp/tests/cp_test.sh | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 147 insertions(+), 5 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.