bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: utimensat round 3


From: Eric Blake
Subject: Re: utimensat round 3
Date: Fri, 16 Oct 2009 06:22:29 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 10/16/2009 5:56 AM:
> Note however, that test-utimens is failing for me
> on an ext4 + Fedora-12-alpha-based system due to this:
> 
>     /* See comment above about this utimecmp call.  */
>     ASSERT (0 <= utimecmp (BASE "file", &st2, &st1, 
> UTIMECMP_TRUNCATE_SOURCE));

Aaargh.  And I also saw a failure on Solaris 9 + NFS on test-futimens, for
the same reason that Solaris 8 was failing test-utimens.

> That utimecmp assertion fails almost all the time due to the
> comparison of two time stamps independently down-sampled
> at different resolutions.
> 
> It wasn't clear right away to me, so I wrote a program to
> call clock_gettime, then utimensat-to-set-to-NOW, then stat.
> Compare the clock_gettime result with st_mtime second and nanosecond values.
> 
> I see ~1-millisecond-resolution FS timestamps
> and higher-resolution clock_gettime times:

Similar to what I'm seeing on cygwin - the default system clock is
documented online as being about 15.25 milliseconds (more like 1/64
second), but can be reduced as low as 1 millisecond.  All timestamps
created by Windows use the default system clock, even though Windows also
provides an API with more resolution (100 nanoseconds) and closer accuracy
(depending on processor speed, can detect increments as small as a couple
of microseconds).  So it creates the same situation - practically any
timestamp created using clock_gettime will appear newer than the
corresponding timestamp created by a system event, even though both would
quantize to the same value.  But utimecmp is only worrying about
resolution, not quantization.

> This failure may also be due to the way utimecmp works,
> but I haven't delved into that code today.

So yes, I'm starting to think we need to teach utimecmp about
quantization, and declare two mtimes as equal if they would both quantize
to the same value (even if they have distinct values due to higher
resolution).  But how to determine quantization of a given filesystem?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrYZYUACgkQ84KuGfSFAYATuQCfQJ+qIwZmTXgbCwo8kixtB++j
U3cAoKEWH8yB1cckYkrwYZgKbqNhFFOm
=1pCZ
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]