Bug 6836 - Samba does not set timestamps properly on newer Linux (2.6.26 and later)
Summary: Samba does not set timestamps properly on newer Linux (2.6.26 and later)
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-10-21 10:31 UTC by Steve French
Modified: 2009-11-05 02:29 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Steve French 2009-10-21 10:31:51 UTC
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).
Comment 1 Björn Jacke 2009-10-21 10:45:36 UTC
For both calls, the new file timestamps are specified in the array times:
times[0] specifies the new "last access time" (atime); times[1] 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.
Comment 2 Björn Jacke 2009-11-04 08:59:34 UTC
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? :-)
Comment 3 Jeremy Allison 2009-11-04 16:13:19 UTC
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.
Comment 4 Björn Jacke 2009-11-05 02:29:29 UTC
yes that's probably safer. Who knows which bugs are still hidden in that call. Closing bug this now as fixes.