From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Redirecting output from running proc doesn't modify the "last modified time" field for target file
Date: Sat, 03 Dec 2011 20:37:00 -0000 [thread overview]
Message-ID: <20111203203656.GA12518@calimero.vinschen.de> (raw)
In-Reply-To: <4ED92F64.4060905@redhat.com>
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
next prev parent reply other threads:[~2011-12-03 20:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 16:51 ajshower
2011-12-02 17:20 ` Jon Clugston
2011-12-02 18:43 ` ajshower
2011-12-02 18:50 ` Jon Clugston
2011-12-02 20:05 ` Eric Blake
2011-12-03 20:37 ` Corinna Vinschen [this message]
2011-12-03 20:58 ` Christopher Faylor
2011-12-02 20:23 ` Eliot Moss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111203203656.GA12518@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).