To set nanosecond (or in our case 100 nanosecond timestamps) properly the posix call utimensat was created. Alternatives (such as utime and utimes) have 1 microsecond or worse granularity and could require Samba to store these timestamps in extended attributes to achieve desired granularity. utimensat was implemented in Linux more than 2 years ago (certainly since 2.6.26 kernel) and added to libc. ext4 and various other Linux local file systems support 100 nanosecond granularity on disk (xfs, jfs etc.).
Man page http://www.kernel.org/doc/man-pages/online/pages/man2/utimensat.2.html describes the function.
We should be using utimensat where available instead of the older utime (utimes) call to set timestamps otherwise we will need to store times either inaccurately (or save them in xattrs which is undesirable).
For both calls, the new file timestamps are specified in the array times:
times specifies the new "last access time" (atime); times specifies the new "last modification time" (mtime).
very uncool, they standarized a new call and missed a great chance to add the functionality to allow setting ctime and btime.
fixed in mater and 3.5 51cb96271b. IHMO think this could go in to 3.4, too. Jeremy, do you like to ack the 3.4 cherry-pick request? :-)
To be honest I think this is too risky for 3.4.x. I'd rather keep in 3.5.0 for now and do more testing.
yes that's probably safer. Who knows which bugs are still hidden in that call. Closing bug this now as fixes.