Messages in this thread Patch in this message | | | Subject | ext2 rename() and the inode ctime of the renamed file/directory | Date | Fri, 3 Sep 1999 23:31:08 -0400 | From | Chris Siebenmann <> |
| |
At the moment, rename()ing something on an ext2 filesystem will update the inode ctimes of the directory or directories it was in or moved between, but it doesn't update the inode ctime of the renamed thing itself.
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/
| |