Why do we update ctime in generic_file_write?

Why do we update ctime in generic_file_write?

[Steven French]

I saw the place in 2.4's generic_file_write in which
       inode->i_ctime = inode->i_mtime = CURRENT_TIME;
but I didn't see such a line in 2.5.56 or 2.5.58
Are you seeing it set somewhere else, less obvious,
in this path?   The writeups I found on st_ctime
would indicate that, as you noticed, it should not
be set there - POSIX spec said:
      "for changed file status, for example, chmod()"
and the man page on fstat says:
      "is changed by writing or setting inode information
      (ie owner, group, link count, mode)"

Andreas Dilger wrote:
>I was looking at the code in generic file write (both 2.4 and 2.5) and in
>both cases we update the ctime always.  My understanding here is that the
>mtime reflects the data modification time, while the ctime reflects the
>inode change time, so we should only be updating the ctime (at most) if
>the file size was increased, and not if we are overwriting data.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench@us.ibm.com

Re: Why do we update ctime in generic_file_write?

[Andreas Dilger]

On Jan 21, 2003  19:34 -0600, Steven French wrote:
> I saw the place in 2.4's generic_file_write in which
>        inode->i_ctime = inode->i_mtime = CURRENT_TIME;
> but I didn't see such a line in 2.5.56 or 2.5.58
> Are you seeing it set somewhere else, less obvious, in this path?

In 2.4, generic_file_write() calls update_inode_times(inode) which
updates both mtime and ctime if they are at least a second old.
In 2.5 it calls inode_update_time(inode, 1) which updates the mtime,
and the "1" indicates that the ctime should be updated (both are
updated only if the time is over a second old).

> The writeups I found on st_ctime would indicate that, as you noticed,
> it should not be set there - POSIX spec said:
>       "for changed file status, for example, chmod()"
> and the man page on fstat says:
>       "is changed by writing or setting inode information
>       (ie owner, group, link count, mode)"

Good.

> Andreas Dilger wrote:
> >I was looking at the code in generic file write (both 2.4 and 2.5) and in
> >both cases we update the ctime always.  My understanding here is that the
> >mtime reflects the data modification time, while the ctime reflects the
> >inode change time, so we should only be updating the ctime (at most) if
> >the file size was increased, and not if we are overwriting data.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Why do we update ctime in generic_file_write?

[Andreas Dilger]

I was looking at the code in generic file write (both 2.4 and 2.5) and in
both cases we update the ctime always.  My understanding here is that the
mtime reflects the data modification time, while the ctime reflects the
inode change time, so we should only be updating the ctime (at most) if
the file size was increased, and not if we are overwriting data.

Anyone have any good rationale for the current behaviour?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Why do we update ctime in generic_file_write?

[Trond Myklebust]

>>>>> " " == Andreas Dilger <adilger@clusterfs.com> writes:

     > I was looking at the code in generic file write (both 2.4 and
     > 2.5) and in both cases we update the ctime always.  My
     > understanding here is that the mtime reflects the data
     > modification time, while the ctime reflects the inode change
     > time, so we should only be updating the ctime (at most) if the
     > file size was increased, and not if we are overwriting data.

See the Single UNIX Specification on
   http://www.opengroup.org/cgi-bin/sussearch.pl

st_ctime is always supposed to be updated whenever st_mtime is
(although the converse is not true).

Cheers,
  Trond