On most other systems with a kernel rename(), it appears to update
the rename()'d object's inode ctime. I believe this is the original
BSD behavior (it's listed as such in the 4.3 Tahoe stat(2) manpage),
and it's also what SGI's EFS and XFS filesystems do.
While not updating the rename'd object's ctime appears to be allowed
by the Opengroup's online Single Unix Spec (the only source of Unix
'standard(s)' that I have handy), it's at odds with historical behavior.
It also seems to be expected by some applications; Legato's Networker
client backup program doesn't incrementally backup renamed files because
of this, for example.
Is there some deep reason for this difference in Linux?
If this is considered a bug, I believe the following tiny patch should
fix things (if it's buggy, let me know, because we run it here[*]).
It's against 2.2.12, but I expect it should apply to 2.3.* easily, and
similar one can be made to 2.0.*.
--- fs/ext2/namei.c 1999/08/30 19:18:51 1.1
+++ fs/ext2/namei.c 1999/08/30 19:21:08
@@ -883,6 +883,13 @@
new_dir->i_version = ++event;
/*
+ * Like most other Unix systems, set the ctime for inodes on a
+ * rename.
+ */
+ old_inode->i_ctime = CURRENT_TIME;
+ mark_inode_dirty(old_inode);
+
+ /*
* ok, that's it
*/
new_de->inode = le32_to_cpu(old_inode->i_ino);
- cks
PS: if this is considered a bug, authors of other filesystems might want
to check theirs to see if it behaves the same as ext2.
[*: It was decided that getting our incremental backups working shouldn't
wait for Legato to fix their bug/assumption.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/