Patch for cp(1)

Bruce Evans bde at
Sat Apr 2 00:10:10 PST 2005

On Fri, 1 Apr 2005, Tom Rhodes wrote:

> On Fri, 1 Apr 2005 20:43:02 +1000 (EST)
> Bruce Evans <bde at> wrote:
>> On Thu, 31 Mar 2005, Tom Rhodes wrote:
>>> On Thu, 31 Mar 2005 15:30:44 +1000 (EST)
>>> Bruce Evans <bde at> wrote:

>>>> Any change to the semantics of -r would break applications that depend on
>>>> its historical behaviour.  Any change that doesn't change the man page would
>>>> be more broken.
>>> What, it would actually copy special files now?  That seems to
>>> be a good thing.
>> No, it would be incompatible.
> How exactly.  That is what I'm not getting.  It will still do
> a recursive copy.  Scripts using -r should still work as before.

No, they would start copying symlinks instead of following symlinks,
and the might hang on special files, etc.

> But how would this be any different from when POSIX does remove
> -r as planned?  Would we wait for everyone else to catch up
> before removing the option?  Or just leave it for another several
> years?

When -r is removed, anything that uses it will break, but if its
behaviour is changed, anything that uses it may silently do the
wrong thing.

>>>>> The -r option fails (actually hangs) when trying to copy a fifo
>>>>> file within a directory.  It does this on both CURRENT,
>>>>> STABLE and SunOS 5.9.
>>>> This is the documented behaviour.
>>> No, this is not the documented behavior.  If this was the truth,
>>> the documenation would say:
>> No, the documented behaviour is that the copy is done incorrectly.
>> Giving more details would be like documenting undefined behaviour.
> Giving more details on what really happens is bad?  I'd like to
> know that the process might be sleeping rather than seeming to
> have hung or perhaps copying forever.

Yes, generally giving too many implementation details is bad, because
it restricts the implementation by forcing it to implement those
details "forever".  This is not so bad if implementation details
are clearly marked as such.

>>>> -r is historical.  POSIX permits it to be implementation-defined
>>>> to prevent breaking it.
>>> And we won't be breaking it.  We won't be bringing it back.
>>> We're only going to remove it's functionality and let it work
>>> as if to be -R.
>> Changing it is the same as breaking it, since its purpose is to
>> be (backwards) compatible.
> In many ways, it will be.  I've enjoyed this conversation but
> for such a small patch, I doubt the energy exists to continue
> much beyond another email or two.  :(

Here are some more quotes from POSIX.1-200x-draft7:

10487                 The difference between -R and -r is in the treatment by cp of file types other than regular and
10488                 directory. The original -r flag, for historic reasons, does not handle special files any differently
10489                 from regular files, but always reads the file and copies its contents. This has obvious problems in
10490                 the presence of special file types; for example, character devices, FIFOs, and sockets. The -R
10491                 option is intended to recreate the file hierarchy and the -r option supports historical practice. It
10492                 was anticipated that a future version of this volume of IEEE Std 1003.1-200x would deprecate
10493                 the -r option, and for that reason, there has been no attempt to fix its behavior with respect to
10494                 FIFOs or other file types where copying the file is clearly wrong. However, some
10495                 implementations support -r with the same abilities as the -R defined in this volume of
10496                 IEEE Std 1003.1-200x. To accommodate them as well as systems that do not, the differences
10497                 between -r and -R are implementation-defined. Implementations may make them identical.
10498                 The -r option is now marked obsolescent.
10531                 The -r option is historical practice on BSD and BSD-derived systems, copying file hierarchies as
10532                 opposed to single files. This functionality is used heavily in historical applications, and its loss
10533                 would significantly decrease consensus. The -R option was added as a close synonym to the -r
10534                 option, selected for consistency with all other options in this volume of IEEE Std 1003.1-200x
10535            that do recursive directory descent.

POSIX introduced the -R flag because fixing the -r flag was too hard because
the fixed version would be incompatible on thos systems that already had
the -r flag (which are primarily BSD systems according to the rationale).
Your change is only correct if:
- fixing the -r flag is no longer too hard on FreeBSD systems, and
- fixing it won't make untangling the flags harder.


More information about the freebsd-standards mailing list