Hi, I admit this is a very special case, but anyway this is what I hit:
$ touch blub; ln -s blub blab; ls -l; cp -f blub blab
total 0
lrwxr-xr-x 1 madroach wheel 4 Oct 30 17:39 blab -> blub
-rw-r--r-- 1 madroach wheel 0 Oct 30 17:39 blub
cp: blab and blub are identical (not copied).
Now I had a look at our cp.c, our cp(1) and at POSIX:
-f For each existing destination pathname, remove it and create a
new file, without prompting for confirmation, regardless of its
permissions. The -f option overrides any previous -i options.
POSIX says cp must always first try to open(2)(O_TRUNC) the destination
and only if this fails AND -f was specified should it try unlink(2).
At least regarding this special case our cp behaves according to
POSIX, not according to our manpage.
As long as we cannot change the POSIX standard I don't know whether our
manpage should mention this or cp.c be changed to use lstat(), too.
Maybe this is such a special case we could just ignore it...
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
signature.asc
Description: PGP signature
