[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.