From owner-freebsd-bugs@FreeBSD.ORG Mon May 4 19:30:04 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E4861065673 for ; Mon, 4 May 2009 19:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32C848FC18 for ; Mon, 4 May 2009 19:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n44JU4Us077790 for ; Mon, 4 May 2009 19:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n44JU3nG077786; Mon, 4 May 2009 19:30:03 GMT (envelope-from gnats) Date: Mon, 4 May 2009 19:30:03 GMT Message-Id: <200905041930.n44JU3nG077786@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: bin/133907: cp(1) wrongly reports errors in vacuous copy X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:30:04 -0000 The following reply was made to PR bin/133907; it has been noted by GNATS. From: Jaakko Heinonen To: james@jrv.org Cc: bug-followup@FreeBSD.org Subject: Re: bin/133907: cp(1) wrongly reports errors in vacuous copy Date: Mon, 4 May 2009 22:21:38 +0300 Hi, On 2009-04-22, james@jrv.org wrote: > $ mkdir x y > $ cp -Rp x/ y > cp: utimes: y/x: No such file or directory > cp: chown: y/x: No such file or directory > cp: chmod: y/x: No such file or directory > cp: chflags: y/x: No such file or directory > $ > > Appears to affect only the vacuous case of arg x being an empty > directory, and only if -p is used. The problem is that in empty directory case fts(3) returns the path name without trailing slash in post-order phase. This results an incorrect value for "base". It's somewhat unexpected that fts(3) returns with different path name in post-order because the fts(3) manual page states: FTS_DP A directory being visited in post-order. The contents of the FTSENT structure will be unchanged from when it was returned in pre- order, i.e., with the fts_info field set to FTS_D. This happens only with FTS_NOCHDIR option used by cp(1). However there is actually no need to set the base value in post-order phase. This patch should fix the problem. --- patch begins here --- Index: bin/cp/cp.c =================================================================== --- bin/cp/cp.c (revision 191680) +++ bin/cp/cp.c (working copy) @@ -316,7 +316,8 @@ copy(char *argv[], enum op type, int fts * Since the first level MUST be FTS_ROOTLEVEL, base * is always initialized. */ - if (curr->fts_level == FTS_ROOTLEVEL) { + if (curr->fts_level == FTS_ROOTLEVEL && + curr->fts_info != FTS_DP) { if (type != DIR_TO_DNE) { p = strrchr(curr->fts_path, '/'); base = (p == NULL) ? 0 : --- patch ends here --- The fts(3) problem may be worth of fixing but I think that the cp(1) change is justified because the fts(3) (mis)behavior seems to exist on other OSes too. -- Jaakko