From owner-freebsd-fs@FreeBSD.ORG Mon Nov 26 07:00:06 2007 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F79716A41A for ; Mon, 26 Nov 2007 07:00:06 +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 1EE9F13C43E for ; Mon, 26 Nov 2007 07:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lAQ705M6012440 for ; Mon, 26 Nov 2007 07:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lAQ705ue012439; Mon, 26 Nov 2007 07:00:05 GMT (envelope-from gnats) Date: Mon, 26 Nov 2007 07:00:05 GMT Message-Id: <200711260700.lAQ705ue012439@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: misc/118249: moving a directory changes its mtime X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 07:00:06 -0000 The following reply was made to PR bin/118249; it has been noted by GNATS. From: Bruce Evans To: Joe Peterson Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/118249: moving a directory changes its mtime Date: Mon, 26 Nov 2007 17:54:12 +1100 (EST) 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