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. Unfortunately the designers of utimensat() didn't think of setting of birth times on systems that have it. It would have been nice if this brand new call had covered this, too. The FreeBSD folks thought about adding a system call to set birth time. All they currently have is a rather hackish[1] way to modify it timewise in one direction. Cheers Björn [1] http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?utimes+2 ... For file systems that support file birth (creation) times (such as UFS2), the birth time will be set to the value of the second element if the second element is older than the currently set birth time.
Attachment:
pgpR3sY6ed1Ue.pgp
Description: PGP signature
