From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18970 invoked by alias); 3 Dec 2011 20:58:25 -0000 Received: (qmail 18958 invoked by uid 22791); 3 Dec 2011 20:58:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mho-03-ewr.mailhop.org (HELO mho-01-ewr.mailhop.org) (204.13.248.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Dec 2011 20:58:07 +0000 Received: from pool-173-76-42-41.bstnma.fios.verizon.net ([173.76.42.41] helo=cgf.cx) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RWwet-000D7x-8Q for cygwin@cygwin.com; Sat, 03 Dec 2011 20:58:07 +0000 Received: from localhost (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 8EC4913C0D3 for ; Sat, 3 Dec 2011 15:58:06 -0500 (EST) X-Mail-Handler: MailHop Outbound by DynDNS X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/aDBktJr34C2LCRoRYY76w Date: Sat, 03 Dec 2011 20:58:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Redirecting output from running proc doesn't modify the "last modified time" field for target file Message-ID: <20111203205806.GA23589@ednor.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <32903475.post@talk.nabble.com> <32904332.post@talk.nabble.com> <4ED92F64.4060905@redhat.com> <20111203203656.GA12518@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111203203656.GA12518@calimero.vinschen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-12/txt/msg00048.txt.bz2 On Sat, Dec 03, 2011 at 09:36:56PM +0100, Corinna Vinschen wrote: >On Dec 2 13:04, Eric Blake wrote: >> On 12/02/2011 11:50 AM, Jon Clugston wrote: >> > While this loop is running, the timestamp on "x.log" doesn't change >> > (whereas on Linux it changes every 10 seconds). It sure looks to me >> > that Windows just doesn't bother updating the file timestamp while it >> > is open. I don't know if this update is required by POSIX - I would >> > doubt that it is. >> >> POSIX requires that any write() to an open file mark it for update; the >> update doesn't have to occur right away (so you can batch up several >> writes, but only change the mtime metadata once at the end of the >> batch), but it DOES require that stat() and several similar functions >> flush all marked updates prior to exposing timestamps to the user. So >> yes, Windows is violating POSIX, and I have no idea whether cygwin can >> work around it. > >You can change all file operations to use FILE_WRITE_THROUGH and >FILE_NO_INTERMEDIATE_BUFFERING. Downside: No caching. All file >operations must be sector aligned. Degraded system performance. >Broken when a process has only write permissions. > >Alternatively, change write(2) so that every WriteFile call is >accompanied by a FlushFileBuffers call. Downside: Extremly degraded >write performance. > >Alternatively: Lie. That's how SUA does it. It has a background >service running which (among other things) keeps track of write >operations of SUA applications. If a SUA application calls write(2) >the write timestamp is kept up to date internally, while the metadata >on disk is still lagging in Windows style. A SUA application calling >stat(2) gets a POSIX compatible timestamp. Non-SUA apps continue to >show the "wrong" timestamp. If non-SUA apps write to a file, SUA apps >also show the Windows timestamp. Cygwin could do the same. Downside: >We don't have a mandatory background service running. Quite a hoop to >jump through to implement a usually non-critical POSIX requirement. Since I believe that this has come up before is anyone willing to provide a FAQ entry that we can point to in the future? cgf -- 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