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

[Christof Schmitt]

Jeremy Allison <jra at samba.org> wrote on 02/14/2012 12:05:07 PM:
> 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.

Ok, thank you for explaining this. It looks like i mixed up two
things: One is storing the ctime if the filesystem allows this
and the other thing is mapping the ctime back the CIFS
timestamps.

I will drop this patch and discuss internally how we want to
proceed with storing all timestamps in gpfs.

Thanks,

Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
christof.schmitt at us.ibm.com  ||  +1-520-799-2469  (T/L: 321-2469)