Page MenuHomeFreeBSD

cp: fix some cases with infinite recursion
ClosedPublic

Authored by kevans on Jan 19 2022, 5:06 AM.
Tags
None
Referenced Files
F154214226: D33944.id102002.diff
Mon, Apr 27, 4:25 AM
Unknown Object (File)
Mon, Apr 20, 2:36 AM
Unknown Object (File)
Sun, Apr 19, 1:00 AM
Unknown Object (File)
Thu, Apr 16, 10:23 AM
Unknown Object (File)
Tue, Apr 14, 2:21 PM
Unknown Object (File)
Tue, Apr 14, 8:08 AM
Unknown Object (File)
Tue, Apr 14, 7:58 AM
Unknown Object (File)
Tue, Apr 14, 7:47 AM
Subscribers

Details

Summary

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable