Redirecting output from running proc doesn't modify the "last modified time" field for target file
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Sat Dec 3 20:58:00 GMT 2011
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
More information about the Cygwin
mailing list