Re: utimes() vs. close()

[Paul Eggert]

Eric Blake <address@hidden> writes:

> CVS cygwin has now been patched so that utimes() first searches for
> open file descriptors visiting the same name, so that utimes() can
> clear the scheduled update and close() no longer interferes, so no
> patch is needed to coreutils.

That fixes this particular problem, but it still doesn't sound right
to me in general.  If a process does this:

     int fd = open("file.out", O_WRONLY);
     write(fd, "...", 3);
     t = time(0);
     close(fd);
     stat("file.out", &sb);

then (assuming all system calls succeed, and nobody else is modifying
the file, and the clock isn't set back) it must be the case that
sb.st_mtime <= t.  That is because the file was last-modified before
time() was called.  However, it sounds like, under the current Cygwin
approach, we might have t < sb.st_mtime.

"Scheduled for update" merely means that another process might not see
the new st_mtime right away.  It doesn't mean that the implementation
can put a post-dated value into st_mtime.

I guess Cygwin could address the issue by storing the last-modified
time in the open file, rather than storing a bit saying that the file
got modified some time in the recent past.