ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime

Steve French smfrench at gmail.com
Thu Oct 22 15:50:44 MDT 2009

On Wed, Oct 21, 2009 at 6:03 PM, Björn Jacke <bj at sernet.de> 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 at henriknordstrom.net> 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.



More information about the samba-technical mailing list