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. 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.
Responsible Changed From-To: freebsd-bugs->freebsd-fs reassign to filesystem guru's ;)
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
A couple of notes on this... * It does not happen with, e.g., ZFS, so it appears to be UFS-specific. * When doing cp -pR, it does not happen. * Along these lines, I tried moving files and dirs *across* file systems, and it does not happen. So it's the case of moving a dir to another dir in the *same* fs that invokes the issue. Since moving across filesystems (according to the man page) uses "rm -f dest && cp -pRP source dest && rm -rf source" rather than rename, this makes sense. P.S. I used the web-form to submit the bug, so the text box must treat the text as one long line (hence the 417 character line).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped