From owner-freebsd-current@FreeBSD.ORG  Thu Dec  1 11:28:38 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1233)
	id 0876F1065673; Thu,  1 Dec 2011 11:28:38 +0000 (UTC)
Date: Thu, 1 Dec 2011 11:28:38 +0000
From: Alexander Best <arundel@freebsd.org>
To: freebsd-current@freebsd.org
Message-ID: <20111201112838.GA62127@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: stupid cp(1) behaviour
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 11:28:38 -0000

is there a chance to change cp's behaviour in connection with the -R switch, so
that it stops after the first error? i just ran into the following situation:

1) cp -ai bla /mnt/umass
2) i got a lot of warnings that /mnt/umass was full
3) cp -an bla /mnt/umass
4) ...that didn't work, since cp created 0 byte files for all files it couldn't
   copy in 1.
5) what i had to do is 'find /mnt/umass/bla -type f - size 0 -delete' and then
   try 3 again

of course, if cp would have bailed out after the first error, there still would
be one file with < actual file size. maybe the available filesize could be
checked before crating the file, or another possibility:

implement a new -N switch or so which isn't based on a file's existance, but a
file's checksum.

cheers.
alex