🚀 go-pugleaf

From: djm@eng.umd.edu (David J. MacKenzie)

In article <439@usenix.ORG> ast@cs.vu.nl (Andy Tanenbaum) writes:

       (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...

   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?

In draft 10, cp never ever unlinks files.
In draft 10, all -f does in cp is turn off a previous -i.
I'm going to object to this on the FSF ballot; I think -f should make
it unlink (unconditionally), like it does for mv, ln, and rm, or else
not be specified at all in the standard, since it's not existing
practice.

--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>

Volume-Number: Volume 21, Number 42