Bug 16336 - cp -f does not force
Summary: cp -f does not force
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Keywords:
: 16337 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-16 13:30 UTC by Marius Bezuidenhout
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-03 14:31:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Marius Bezuidenhout 2000-08-16 13:30:19 UTC
Doing a copy with the force flag '-f' does nothing.

Comment 1 Marius Bezuidenhout 2000-08-16 13:36:41 UTC
*** Bug 16337 has been marked as a duplicate of this bug. ***

Comment 2 Tim Waugh 2000-08-16 15:04:14 UTC
As root, cp is aliased to 'cp -i', so when you type 'cp -f ...' it's actually
doing a 'cp -i -f ...'.

Comment 3 Marius Bezuidenhout 2000-08-17 06:44:24 UTC
But it worked in RedHat 6.2.
Should the force not take priority?
Other users should also have "alias cp='cp -i'"

Comment 4 Alan Cox 2000-08-18 16:49:22 UTC
The new behaviour is valid. Its certainly not desirable however


Comment 5 Marius Bezuidenhout 2000-08-21 07:28:51 UTC
Doing a `rm -i -f` does force.
Thus it is expected from `cp -i -f` as well.

Comment 6 Tim Waugh 2000-10-03 14:31:17 UTC
The cp from fileutils-4.0z has this:

-f, --force   if a preexisting destination file cannot be opened, then unlink it
and try again
...
--remove-destination  unlink each preexisting destination file before attempting
to open it (contrast with --force)


Comment 7 Bernhard Rosenkraenzer 2000-10-09 10:00:47 UTC
Check the fileutils changelog - it is intended behavior because of POSIX
compliance.


Note You need to log in before you can comment on or make changes to this bug.