Query about P1003.2 'cp' utility

Andy Tanenbaum ast at cs.vu.nl
Fri Aug 17 19:46:37 AEST 1990


From:  Andy Tanenbaum <ast at cs.vu.nl>

While studying the P1003.2 description of the 'cp' utility, I ran into an
ambiguity. In paragraph 4.13.2 (description), line 1985 & 1996-2000, it says:

    (1) If the destination path exists:

        (b) If the permissions of the file to which the destination path
        refers to do not permit writing, actions are performed equivalent to
        the unlink() #5.5.1[POSIX.1] function call using destination as the
        path argument, and, if this fails for any reason...

In paragraph 4.13.3 (options), next page, lines 2010 & 2011 says:

    -f   For each existing destination pathname, remove it and create a new
         file, without prompting for confirmation regardless of its permissions

Now, I believe that the description should say:

         (b) If the permissions of the file to which the destination path
         refers to do not permit writing, or if the -f option is specified, ...

to be consistent, but then "cp -f" would snap any existing links to the 
destination file, and even change the destination file mode, owner and group 
(without a -p being specified), while "cp" wouldn't.

Example:

-rw-r--r-- 1   user1    group1         srcfile
-rw-rw-rw- 2   user2    group2         dstfile

If user3 (group3) invokes cp srcfile dstfile, then the dstfile's mode, owner,
group and links do not change. However, if cp -f srcfile dstfile is invoked,
then the dstfile becomes:

-rw-r--r-- 1   user3    group3         dstfile

Now, this behavior might be correct, but is this effect really intended by
P1003.2? Possibly, the user that wish to replace the dstfile entirely (as
opposed to overwriting it) should use rm BEFORE calling cp, and the -f option
should be used only to suppress interaction with the user.

Maybe draft 10 clarifies the situation?


Vincent Archer             | Email:archer%segin4.segin.fr at relay.prime.com
"People that are good at finding excuses are never good at anything else"


(Posted by Andy Tanenbaum because Vincent does not have USENET access.)

Volume-Number: Volume 21, Number 41



More information about the Comp.std.unix mailing list