delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/02/09/16:27:42

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From: ericblake AT comcast DOT net
To: cygwin AT cygwin DOT com
Subject: more ctime bugs
Date: Wed, 09 Feb 2005 21:27:23 +0000
Message-Id: <020920052127.27398.420A803A0009BD7500006B0622007507440A050E040D0C079D0A@comcast.net>
X-Authenticated-Sender: ZXJpY2JsYWtlQGNvbWNhc3QubmV0

Corinna, since you've been fixing so many ctime bugs lately to match SUSv3 and POSIX, could you also fix open(2) when O_TRUNC is set, and write(2) and link(2) in general, to touch ctime?  I guess this all stems from the fact that the Microsoft documentation for Windows file systems calls out the 3 file times as "create, access, and write", with access updates occuring on read or write; while POSIX names the three times as "file status change, file data access, and file data modify", with access updates only required on read (but allowed on write as an implementation extension).  Status changes certainly happen more often than creation, so the meaning of ctime is drastically different depending on which word you substitute for 'c'!

I found the problem with link(2) from the coreutils testsuite, and the others by browsing this search on the POSIX docs: http://www.opengroup.org/cgi-bin/susv3search.pl?KEYWORDS=st_ctime+update&SUBSTRING=substring&CONTEXT=%28%2Ffunctions%2F%29

$ rm a b
$ touch a
$ stat a
  File: `a'
  Size: 0               Blocks: 0          IO Block: 1024   regular empty file
Device: 10292fb1h/271134641d    Inode: 17451448556181969  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (22382/  eblake)   Gid: (10513/Domain Users)
Access: 2005-02-09 12:15:49.179375000 -0700
Modify: 2005-02-09 12:15:49.179375000 -0700
Change: 2005-02-09 12:15:49.179375000 -0700
$ ln a b    # calls link(2)
$ echo a > a    # calls open(2) with O_TRUNC, and calls write(2)
$ stat a
  File: `a'
  Size: 2               Blocks: 1          IO Block: 1024   regular file
Device: 10292fb1h/271134641d    Inode: 17451448556181969  Links: 2
Access: (0666/-rw-rw-rw-)  Uid: (22382/  eblake)   Gid: (10513/Domain Users)
Access: 2005-02-09 12:15:55.804375000 -0700
Modify: 2005-02-09 12:15:55.804375000 -0700
Change: 2005-02-09 12:15:49.179375000 -0700
# Oops, ctime unchanged

It is also interesting to note that Microsoft documents that for FAT, mtime has a resolution of only 2 sec, but ctime has a resolution of 10 ms.  There are a lot of scripts out there that end up using `sleep 2' to ensure two files in FAT have different mtime stamps, since POSIX requires make(1) to use mtime and not ctime to determine when one file is older than another.  If ctime is consistently updated on writes, perhaps cygwin make could use ctime as a tiebreaker between two files with the same mtime to reduce the need for the sleep 2.

--
Eric Blake

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019