Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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/