Date: Mon, 26 Nov 2007 07:00:05 GMT From: Bruce Evans <brde@optusnet.com.au> To: freebsd-fs@FreeBSD.org Subject: Re: misc/118249: moving a directory changes its mtime Message-ID: <200711260700.lAQ705ue012439@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/118249; it has been noted by GNATS. From: Bruce Evans <brde@optusnet.com.au> To: Joe Peterson <lavajoe@gentoo.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711260700.lAQ705ue012439>