Bug 235438
| Summary: | cp -R command not working properly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Ioannis Vranos <ioannis.vranos> | ||||
| Component: | bin | Assignee: | Kyle Evans <kevans> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Many People | CC: | bugs, chris, ioannis.vranos, kevans, rb | ||||
| Priority: | --- | Flags: | kevans:
mfc-stable13?
kevans: mfc-stable12? |
||||
| Version: | 12.0-RELEASE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: | https://reviews.freebsd.org/D33944 | ||||||
| Attachments: |
|
||||||
POSIX apparently allows the current behaviour but it does not seem sensible. The proposed alternative seems reasonable. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=848263aad129c8f9de75b58a5ab9a010611b75ac commit 848263aad129c8f9de75b58a5ab9a010611b75ac Author: Kyle Evans <kevans@FreeBSD.org> AuthorDate: 2022-01-27 18:02:17 +0000 Commit: Kyle Evans <kevans@FreeBSD.org> CommitDate: 2022-01-27 18:02:17 +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. Differential Revision: https://reviews.freebsd.org/D33944 bin/cp/cp.c | 75 +++++++++++++++++++++++++++++++++++++++++++---- bin/cp/tests/cp_test.sh | 77 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+), 5 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5237a02ba86b5957d10d87148bbc0efb3f2f6f82 commit 5237a02ba86b5957d10d87148bbc0efb3f2f6f82 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:51:13 +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(-) 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(-) ^Triage: apparently committed back in 2022. Now in all supported releases. |
Created attachment 201655 [details] It shows the cp -R directory bug The command cp -R has a bug when copying. An example: cp -R Downloads Downloads produces a recursive copying, until it reaches some recursion limits. See the screenshot attached. It should follow the Linux cp -R behaviour: Create only one copy of the directory, in itself, and then quit.