From owner-freebsd-current@FreeBSD.ORG Wed Nov 21 08:27:02 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123A316A418; Wed, 21 Nov 2007 08:27:02 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 883F513C469; Wed, 21 Nov 2007 08:27:01 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id lAL85DPe017176; Wed, 21 Nov 2007 10:05:13 +0200 Received: from MX-IN-03.forthnet.gr (mx-in-03.forthnet.gr [193.92.150.26]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id lAL85DUV014362; Wed, 21 Nov 2007 10:05:13 +0200 Received: from [192.168.136.22] (ppp49-143.adsl.forthnet.gr [62.1.66.143]) by MX-IN-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id lAL855Jg009152; Wed, 21 Nov 2007 10:05:06 +0200 Authentication-Results: MX-IN-03.forthnet.gr smtp.mail=dds@FreeBSD.org; spf=permerror Authentication-Results: MX-IN-03.forthnet.gr header.from=dds@FreeBSD.org; sender-id=permerror Message-ID: <4743E697.10701@FreeBSD.org> Date: Wed, 21 Nov 2007 10:04:39 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: d@delphij.net References: <47438516.6060105@delphij.net> In-Reply-To: <47438516.6060105@delphij.net> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, kensmith@FreeBSD.org Subject: Re: Strange behavior of mv(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2007 08:27:02 -0000 Xin LI wrote: > It seems that mv(1) behaves differently when handling with respect to > different filesystems. > > Test1: Moving within one filesystem: > > mkdir -p t/a/b > mkdir -p b/c/d > cd t/ > mv ../b a > > Resulting tree: > t/ > a/ > b/ > c/ > d/ > > However, with different filesystems: > > mkdir -p t/a/b > mkdir -p /tmp/b/c/d > cd t > mv /tmp/b a > > We get: > > t/ > a/ > b/ > b/ > c/ > d/ > > I think the second behavior is not correct? Yes, the second behavior is not correct. The first, behaves according to the specification of mv in IEEE Std 1003.1, 2004 Edition: "The mv utility shall perform actions equivalent to the rename() function defined in the System Interfaces volume of IEEE Std 1003.1-2001, called with the following arguments: 1. The source_file operand is used as the old argument. 2. The destination path is used as the new argument." where "The destination path for each source_file shall be the concatenation of the target directory, a single slash character, and the last pathname component of the source_file." mv -v and truss(1) show that this is the case: rename("../b","a/b") = 0 (0x0) The code used for running the second instance, misses implementing a part of the rename(2) specification: "If the directory named by the new argument exists, it shall be removed and old renamed to new." Currently mv first calls cp, which behaves as follows: cp -PRpv /tmp/b a/b /tmp/b -> a/b/b /tmp/b/c -> a/b/b/c /tmp/b/c/d -> a/b/b/c/d If the destination is first removed, cp behaves as expected: rm -rf a/b cp -PRpv /tmp/b a/b /tmp/b -> a/b /tmp/b/c -> a/b/c /tmp/b/c/d -> a/b/c/d I'd be happy to fix it, if you file a PR assigned to me. There are two issues related to the fix: 1. I think we should do more to preserve the atomicity requirements of rename(2) when we're copying files. Currently if cp(1) or rm(1) fails, stuff is left lying around. If the fix follows the same path, data will also get deleted. 2. How would you feel about linking with mv(1) the code of cp(1) and rm(1)? On i386 the space overhead will be less than 25k, and we will save three fork/exec calls. Diomidis Spinellis - http://www.spinellis.gr