Skip to contentSkip to conversation

New: directory ctime not updated by rename

Bugme-new Andrew Morton 3 participants 5 messages Mar 18, 2008 – Mar 20, 2008 1 message not in the archive VFS

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw
Quoted 53 lines · On Tue, 18 Mar 2008 09:11:54 -0700 (PDT) [email protected] 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: [email protected]
ReportedBy: [email protected]

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>

Quoted 11 lines
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.

maintainer
#2 lore raw
Quoted 2 lines · Andrew Morton

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()).

maintainer
#3 lore raw
Quoted 7 lines · Al Viro
Quoted 2 lines · Andrew Morton

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.

#4 lore raw
In reply to Al Viro
Quoted 7 lines · On Tue, 18 Mar 2008 17:46:09 +0000 Al Viro <[email protected]> wrote:
Quoted 2 lines · Andrew Morton

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

Quoted 1 line

Which filesystem it is, BTW?

ext3.

Quoted 6 lines

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()).

#5 lore raw
In reply to Al Viro

Al Viro:

Quoted 7 lines

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