X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Eric Blake <ebb9 AT byu DOT net>
Subject:	Re: coreutils 6.10-2, cygwin 1.5.25-15, cp -af loss of precision in timestamp
Date:	Tue, 8 Dec 2009 20:59:03 +0000 (UTC)
Lines:	41
Message-ID:	<loom.20091208T214627-55@post.gmane.org>
References:	<4B1EABEF DOT 70206 AT qualcomm DOT com>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Rob Walker <rwalker <at> qualcomm.com> writes:

> 
> I've found that cp -af doesn't preserve the least significant bits of 
> the "Modify" field of a file time.

Yep.  And the same goes for Linux prior to the introduction of the utimensat 
API.  The fix is to upgrade to cygwin 1.7.

Another caveat: any application that doesn't treat all files occurring with 
timestamps within the same 20 millisecond window as the same timestamp are 
doomed to portability problems on various filesystem/OS combinations; see this 
thread on gnulib:
http://lists.gnu.org/archive/html/bug-gnulib/2009-10/msg00140.html

> 
> Ending up with a file with a time stamp of the above fine-grained form 
> is somewhat rare, I had to write a short Windows program to induce it.

Depends on your machine, actually.  On my work machine, I get a non-zero digit 
in the 10^-7 position for 95% of the files I create.  On my home machine cygwin 
installation, ALL of my files are have a 0 in that position (ie. true multiples 
of 1 microsecond or greater).  It is all based on the granularity of your 
system clock interrupts, which in turn depends on your mother board.  Also, 
Windows itself does not permit resolution finer than 100ns, even though some 
filesystems do (like ext3 on Linux).

However, there is still one pending timestamp granularity issue with no known 
patch, where time can STILL appear to go backward when using utimensat, because 
cygwin is using a different hi-res clock than windows:
http://cygwin.com/ml/cygwin-developers/2009-10/msg00209.html

And on the other end of the spectrum - don't try 'sleep 50d' unless you like 
100% CPU utilization; the patch has been posted, but deferred until after 
cygwin 1.7.1:
http://cygwin.com/ml/cygwin-patches/2009-q4/msg00178.html

-- 
Eric Blake




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -