mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-22 11:14:18 +01:00
848263aad1
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 |
||
|---|---|---|
| .. | ||
| cat | ||
| chflags | ||
| chio | ||
| chmod | ||
| cp | ||
| csh | ||
| date | ||
| dd | ||
| df | ||
| domainname | ||
| echo | ||
| ed | ||
| expr | ||
| freebsd-version | ||
| getfacl | ||
| hostname | ||
| kenv | ||
| kill | ||
| ln | ||
| ls | ||
| mkdir | ||
| mv | ||
| pax | ||
| pkill | ||
| ps | ||
| pwait | ||
| pwd | ||
| realpath | ||
| rm | ||
| rmail | ||
| rmdir | ||
| setfacl | ||
| sh | ||
| sleep | ||
| stty | ||
| sync | ||
| test | ||
| tests | ||
| uuidgen | ||
| Makefile | ||
| Makefile.inc | ||