[PATCH] s3: Report ctime as change time, not mtime

[Jeremy Allison]

On Tue, Feb 14, 2012 at 11:39:00AM -0700, Christof Schmitt wrote:
> Jeremy Allison <jra at samba.org> wrote on 02/13/2012 05:59:43 PM:
> 
> > On Mon, Feb 13, 2012 at 11:23:41AM -0700, Christof Schmitt wrote:
> > > I am working on a patch to store the ctime with the
> > > gpfs_set_times() call. While testing setting and storing
> > > timestamps i discovered that querying the timestamps from a cifs
> > > client does not return all four timestamps. It seems that the
> > > mtime is reported for two timestamps and the ctime is being
> > > discarded:
> > > 
> > > E.g. in smbd_do_qfilepathinfo():
> > >         mtime_ts = psbuf->st_ex_mtime;
> > >         ctime_ts = get_change_timespec(conn, fsp, smb_fname);
> > > and get_change_timespec also returns the mtime.
> > > 
> > > The attached patch changes get_change_timespec to return the
> > > ctime, so that all timestamps set through the vfs set_times call can
> > > be queried through the vfs stat calls.
> > 
> > I don't think this is correct, but you'll have to wait
> > until I analyse this more in order to be accurate.
> > 
> > The basic problem is:
> > 
> > UNIX ctime != Windows change time.
> > 
> > Jeremy.
> > 
> 
> Hi Jeremy,
> 
> thanks for looking into this. Here are some more things in found
> for this issue:
> 
> The best testcase seems to be RAW-SFILEINFO in smbtorture: In
> samba/source4/torture/raw/setfileinfo.c the step "Test basic_info
> level\n" sets all four Windows timestamps and expects that
> reading them yields the same values.
> 
> In Samba, the "change time" is mapped to ctime in
> smb_set_file_basic_info():
> 
>         /* create time */
>         ft.create_time = interpret_long_date(pdata);
> 
>         /* access time */
>         ft.atime = interpret_long_date(pdata+8);
> 
>         /* write time. */
>         ft.mtime = interpret_long_date(pdata+16);
> 
>         /* change time. */
>         ft.ctime = interpret_long_date(pdata+24);
> 
> But when reading the timestamps, mtime is mapped to both, "write
> time" and "change time". It seems odd to me that i can write
> the "change time" from a client, but this value will never be
> returned. The patch i submitted seems to be the simplest way to
> change this.

Yes, but it might break a bunch of Windows apps.

The problem is that UNIX ctime != Windows change time. Yes,
we treat it inconsistently on set and get (for set we
pretend it's the same, on get we don't). But that's
an underlying bug in Samba.

The real fix for this is for us to take control of
our own create/write/access/change times and reply
to them with wholely Windows semantics, but that's
a bigger change than we are willing to do right now.

Look at the definition of st_ctime:

"The field st_ctime is changed by writing or by setting
inode information (i.e., owner, group, link count, mode, etc.)."

Now look at the definition of LastChangeTime:

"LastChangeTime: The time that identifies when the file
metadata or contents were last changed"

They're different. LastChangeTime is the greater of
mtime and ctime (from UNIX). Probably. There's the
issue of the 2-second granularity we also don't
fully understand yet.

This isn't the way it works on NTFS. If we pretend it
is we'll run into a host of time-related problems that
currently we avoid.

The best way to proceed on this is to add smbtorture4
tests until we *really* understand the updating of
timestamps on NTFS, then code this into a completely
separate timestamp management function within smbd,
and determine how this maps (mostly) onto ctime,mtime,
atime and friends.

Jeremy.