GNU bug report logs - #12365
Incorrect return value of cp with no-clobber option

Previous Next

Package: coreutils;

Reported by: Anoop Sharma <sendtoanoop <at> gmail.com>

Date: Thu, 6 Sep 2012 11:59:01 UTC

Severity: normal

Tags: wontfix

Done: Eric Blake <eblake <at> redhat.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Blake <eblake <at> redhat.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#12365: closed (Incorrect return value of cp with no-clobber
 option)
Date: Thu, 06 Sep 2012 14:33:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Thu, 06 Sep 2012 08:31:53 -0600
with message-id <5048B3D9.8060903 <at> redhat.com>
and subject line Re: Should cp -n return 0, when DEST exists?
has caused the debbugs.gnu.org bug report #12365,
regarding Incorrect return value of cp with no-clobber option
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
12365: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12365
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Anoop Sharma <sendtoanoop <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Incorrect return value of cp with no-clobber option
Date: Thu, 6 Sep 2012 17:27:52 +0530
When -n (--no-clobber) option of cp is used and the DEST file exists, then, as
expected, cp is not able to copy the SOURCE to DEST.

However, cp returns 0 in this case.

Shouldn't it return 1 to indicate that copy operation could not be completed?

In absence of this indication how is one to know that some recovery
action like re-trying cp with some other DEST name is required?

Regards,
Anoop


[Message part 3 (message/rfc822, inline)]
From: Eric Blake <eblake <at> redhat.com>
To: Anoop Sharma <sendtoanoop <at> gmail.com>
Cc: 12365-done <at> debbugs.gnu.org, coreutils <coreutils <at> gnu.org>
Subject: Re: Should cp -n return 0, when DEST exists?
Date: Thu, 06 Sep 2012 08:31:53 -0600
[Message part 4 (text/plain, inline)]
tag 12365 wontfix
thanks

On 09/06/2012 04:50 AM, Anoop Sharma wrote:
> When -n option of cp is used and the DEST file exists, then, as
> expected, cp is not able to copy the SOURCE to DEST.
> 
> However, cp returns 0 in this case.

cp -n is not mandated by POSIX, so we are free to do as we wish here.
But looking at history, we added -n for coreutils 7.1 in Feb 2009, and
the mail from that thread includes:
https://lists.gnu.org/archive/html/bug-coreutils/2008-12/msg00159.html

which states we are modeling after FreeBSD.  A quick check on my FreeBSD
8.2 VM shows:

$ echo one > bar
$ echo two > blah
$ cp -n blah bar
$ echo $?
0
$ cat bar
one

that FreeBSD also returns 0 in this case, and I don't want to break
interoperability.  Therefore, I'm going to close this as a WONTFIX,
unless you also get buy-in from the BSD folks.

By the way, there's no need to post three separate emails with the same
contents, without first waiting at least 24 hours.  Like most other
moderated GNU lists, you do not have to be a subscriber to post, and
even if you are a subscriber, your first post to a given list will be
held in a moderation queue for as long as it takes for a human to
approve your email address as a non-spammer for all future posts
(generally less than a day).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 12 years and 262 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.