Bug 436083

Summary:	cp -i -f should act sensibly
Product:	[Fedora] Fedora	Reporter:	JW <ohtmvyyn>
Component:	coreutils	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	8	CC:	twaugh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-05 12:03:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description JW 2008-03-05 09:49:37 UTC

Description of problem:
If both -i and -f options (in that order) are specified to cp then cp should not
act interactively. Conversely, if -f and -i options (in that order) are
specified then -f should be ignored.

Version-Release number of selected component (if applicable):
coreutils-6.9-9

How reproducible:
Always

Steps to Reproduce:
1. unalias cp
2. touch a b
3. cp -i -f a b
4. cp -f -i a b
  
Actual results:
3. prompts
4. prompts

Expected results:
3. no prompt
4. prompt

Additional info:
In a sense -i and -f are complimentary.  That is, -i means ask, and -f means
don't ask.  Often users will alias cp='cp -i' to avoid clobbering files.  But
then when they really want to overwrite files unconditionally they will use 'cp
-f' which will translate to 'cp -i -f'.  While it is entirely possible to use
'\cp -f' that assumes that the user is fully conscious of any cp alias in effect.

It would make a lot more sense to have both -f and -i use the same internal
flag, rather than distinct "unlink_dest_after_failed_open" and "interactive",
and thereby the final -i/-f would be the flag that endures.

Comment 1 Ondrej Vasik 2008-03-05 12:03:26 UTC

from cp info page:
`-f'
`--force'
    ...
     This option is independent of the `--interactive' or `-i' option:
     neither cancels the effect of the other.

So IMO this options work as designed and this behaviour is not a bug. 
POSIX specification (defines this behaviour):
http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html
Upstream report with answer:
http://www.mail-archive.com/bug-coreutils@gnu.org/msg11297.html

I'm not going to break POSIX definitions and to create fork of cp in this case,
 therefore closing NOTABUG.