misc/118249: moving a directory changes its mtime

[Bruce Evans]

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