On Wed, Oct 21, 2009 at 6:03 PM, Björn Jacke <bj@xxxxxxxxx> wrote: > On 2009-10-21 at 10:36 -0500 Steve French sent off: >> On Wed, Oct 21, 2009 at 6:59 AM, Henrik Nordstrom >> <henrik@xxxxxxxxxxxxxxxxxxx> wrote: >> > utimen -> nanosecond (struct timespec) (1/1000000000), same granularity >> > as current stat(), clock_gettime() and friends. >> >> Yes. I have opened bug 6836 in samba bugzilla to track having smbd >> use utimensat (but not sure whether they will be able to detect when >> the file system can support nanosecond timestamps through - even with >> use of utimensat - so there may be questions about how to do runtime >> detection of whether the filesystem is one like ext4, xfs, jfs etc. >> that can store such timestamps, if not they probably still have to >> store 100 nanosecond "DCE time" granulariy timestamps in xattrs) > > up to these days Samba just supports the granularity the undelying filesystem > supports and I think there is no need to change this. The utimensat > documentation says: "The file's relevant timestamp shall be set to the greatest > value supported by the file system that is not greater than the specified > time." So just using this call (where available) is all Samba will have to do - > I see nothing more to care about. Time granularity of 1 second on ext3 is so atrociously bad, and ext3 is so common, that I see obvious reason why Samba server would want to store 100 nanosecond time stamps (in xattrs) for this very common case. It would be very confusing to some Windows apps to have time on files seem to move backwards (due to rounding to 1 second granularity) - to set the time to something and have the time when next retrieved (on average) a 1/2 second earlier than what they just set. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
