bin/133907: cp(1) wrongly reports errors in vacuous copy

Jaakko Heinonen jh at saunalahti.fi
Mon May 4 19:30:04 UTC 2009


The following reply was made to PR bin/133907; it has been noted by GNATS.

From: Jaakko Heinonen <jh at saunalahti.fi>
To: james at jrv.org
Cc: bug-followup at 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 at 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


More information about the freebsd-bugs mailing list