Latest working kernel version: Earliest failing kernel version: Distribution: LFS Hardware Environment: 32bit x86 Software Environment: Problem Description: Renaming a file into a directory so that an already existing file is overwritten, will not update the ctime on the directory. This seems to be the reason for certain failures with incremental backups (e.g., with star). Steps to reproduce: Run the following commands and watch the output from stat. Upon the second run of rename, the ctime is not updated on the directory sub. rm -fr sub new && mkdir sub && stat sub && sleep 2 && echo running rename && ./rename a && stat sub && sleep 2 && echo running rename again && ./rename b && stat sub Here is rename.c: #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <sys/stat.h> int main(int argc, char** argv) { int fd; fd = open("new", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT, 0644); write(fd, argv[1], 1); close(fd); rename("new", "sub/x"); return 0; }
Reply-To: akpm@linux-foundation.org On Tue, 18 Mar 2008 09:11:54 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10276 > > Summary: directory ctime not updated by rename > Product: File System > Version: 2.5 > KernelVersion: 2.6.24.3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: ext3 > AssignedTo: akpm@osdl.org > ReportedBy: lasse-kernelbug-2008@mail.plastictree.net > > > Latest working kernel version: > Earliest failing kernel version: > Distribution: LFS > Hardware Environment: 32bit x86 > Software Environment: > Problem Description: Renaming a file into a directory so that an already > existing file is overwritten, will not update the ctime on the directory. > This > seems to be the reason for certain failures with incremental backups (e.g., > with star). > > Steps to reproduce: > > Run the following commands and watch the output from stat. Upon the second > run > of rename, the ctime is not updated on the directory sub. > > rm -fr sub new && > mkdir sub && > stat sub && > sleep 2 && > echo running rename && > ./rename a && > stat sub && > sleep 2 && > echo running rename again && > ./rename b && > stat sub > > > Here is rename.c: > > #include <unistd.h> > #include <fcntl.h> > #include <stdio.h> > #include <stdlib.h> > #include <sys/stat.h> > > int main(int argc, char** argv) { > int fd; > > fd = open("new", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT, 0644); > write(fd, argv[1], 1); > close(fd); > rename("new", "sub/x"); > > return 0; > } > Do we agree that this is a bug? If so, is it a VFS thing or a per-fs thing? Thanks.
Reply-To: viro@ZenIV.linux.org.uk On Tue, Mar 18, 2008 at 10:00:23AM -0700, Andrew Morton wrote: > Do we agree that this is a bug? If so, is it a VFS thing or a per-fs > thing? The latter; all control over timestamps on directory operations is in filesystems. Which filesystem it is, BTW? E.g. ext2 has dir->i_mtime = dir->i_ctime = CURRENT_TIME_SEC; in ext2_set_link() (and the same in ext2_add_entry()/ext2_delete_entry()), so on all paths in ext2_rename() both parents will get ctime and mtime updated; so will the object being moved and the object being unlinked (explicitly in ext2_rename()).
Reply-To: viro@ZenIV.linux.org.uk On Tue, Mar 18, 2008 at 05:46:09PM +0000, Al Viro wrote: > On Tue, Mar 18, 2008 at 10:00:23AM -0700, Andrew Morton wrote: > > > Do we agree that this is a bug? If so, is it a VFS thing or a per-fs > > thing? > > The latter; all control over timestamps on directory operations is in > filesystems. Which filesystem it is, BTW? E.g. ext2 has Doh. ext3... OK, that's a bug; direct update of directory entry by new_de->inode = cpu_to_le32(old_inode->i_ino); needs an update of timestamps of new_dir.
Reply-To: akpm@linux-foundation.org On Tue, 18 Mar 2008 17:46:09 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote: > On Tue, Mar 18, 2008 at 10:00:23AM -0700, Andrew Morton wrote: > > > Do we agree that this is a bug? If so, is it a VFS thing or a per-fs > > thing? > > The latter; all control over timestamps on directory operations is in > filesystems. OK > Which filesystem it is, BTW? ext3. > E.g. ext2 has > dir->i_mtime = dir->i_ctime = CURRENT_TIME_SEC; > in ext2_set_link() (and the same in ext2_add_entry()/ext2_delete_entry()), > so on all paths in ext2_rename() both parents will get ctime and mtime > updated; so will the object being moved and the object being unlinked > (explicitly in ext2_rename()).
Reply-To: hooanon05@yahoo.co.jp Al Viro: > The latter; all control over timestamps on directory operations is in > filesystems. Which filesystem it is, BTW? E.g. ext2 has > dir->i_mtime = dir->i_ctime = CURRENT_TIME_SEC; > in ext2_set_link() (and the same in ext2_add_entry()/ext2_delete_entry()), > so on all paths in ext2_rename() both parents will get ctime and mtime > updated; so will the object being moved and the object being unlinked > (explicitly in ext2_rename()). Is it correct to update the mtime of renaming inode? When it is a regular file the mtime is not updated, but a directory. I have been wondering it for a long time. $ stat -f . File: "." ID: c39e8aabce296ceb Namelen: 255 Type: ext2/ext3 Block size: 1024 Fundamental block size: 1024 Blocks: Total: 124442 Free: 122443 Available: 116018 Inodes: Total: 32256 Free: 32144 (actually it is ext2) $ mkdir d1 $ stat d1 File: `d1' Size: 1024 Blocks: 2 IO Block: 1024 directory Device: 30ah/778d Inode: 2017 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 1000/ jro) Gid: ( 1000/ jro) Access: 2008-03-20 12:33:57.000000000 +0900 Modify: 2008-03-20 12:33:57.000000000 +0900 Change: 2008-03-20 12:33:57.000000000 +0900 $ /tmp/rename d1 d2 (simply issues rename systemcall.) $ stat d2 File: `d2' Size: 1024 Blocks: 2 IO Block: 1024 directory Device: 30ah/778d Inode: 2017 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 1000/ jro) Gid: ( 1000/ jro) Access: 2008-03-20 12:33:57.000000000 +0900 Modify: 2008-03-20 12:34:11.000000000 +0900 Change: 2008-03-20 12:34:11.000000000 +0900 $ Junjiro Okajima
Created attachment 15443 [details] Fix mtime update on rename This patch fixes the problem.
(In reply to comment #6) > Created an attachment (id=15443) [details] > Fix mtime update on rename > > This patch fixes the problem. > I've tested the patch for some time now. It makes incremental backups work fine. I noticed that mtime is updated as well now. My original request was only for ctime, but maybe there are good reasons to have the mtime updated as well.
I think according to specs both times should be changed...
The patch already went to Linus's tree so I'm closing the bug.