From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 26 06:54:36 2007 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09DF16A419; Mon, 26 Nov 2007 06:54:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8E49813C447; Mon, 26 Nov 2007 06:54:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAQ6sCox025609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 17:54:15 +1100 Date: Mon, 26 Nov 2007 17:54:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Joe Peterson In-Reply-To: <200711252133.lAPLX5iq062255@www.freebsd.org> Message-ID: <20071126172840.R99137@delplex.bde.org> References: <200711252133.lAPLX5iq062255@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/118249: moving a directory changes its mtime X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 06:54:37 -0000 On Sun, 25 Nov 2007, Joe Peterson wrote: >> Description: > Moving a directory to a different directory changes its "mtime". This behavior seems odd compared with other "Unix" systems (tried on Mac OS X and Linux). Also, moving a file to a different directory does *not* change its mtime, making this behavior inconsistent. Also, it is not typically desirable to touch mtime simply by being moved, which loses track of the last time the dir's contents were actually changed. Please use line much shorter than 417 characters. >> How-To-Repeat: > mkdir a b > (check timestamps using stat or "ls -ld" and "ls -lcd") > mv b a > (check timestamps again) > > Both "a" and "b" will now have new mtime and ctime). It is expected that "a" will have a new mtime and ctime, but only the ctime on "b" should have changed. b's contents did change -- its ".." entry moved. However, POSIX only requires marking for update the ctime and mtime of the parent directory for each file (only upon successful completion). I've been running regression tests on timestamps for rename() for more than 15 years and am surprised that they don't notice this bug. The (mis)implementation of marking for update the ctime and mtime of the moved directory seems to be just to call some function (probably ufs_direnter()) which does the marking. ufs_rename() only sets IN_CHANGE and IN_RENAME directly. ufs_rename() has a related bug on unsuccessful completion. It unnecessarily marks IN_CHANGE near its beginning, long before successful completion, so rename() usually clobbers ctimes on failure. This is easy to fix by setting the correct flag for marking inode modifications (IN_MODIFIED). (IN_CHANGE used to mean inode-modified, but is now just the ctime update mark, apart from this and some similar bugs.) With this fix, there are no direct settings of IN_CHANGE left in ufs_rename(). According to my notes, ufs_direnter() and ufs)dirremove are resposible for marking all the necessary updates, and they have the same bug of doing this before successful completion. My regression tests haven't reported any failures from them but I think failures can occur for disk-full and I/O errors and the former is easy to test. mv across file systems clobbers directory times and much more (links...). Bruce