[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: utimes() vs. close()
From: |
Paul Eggert |
Subject: |
Re: utimes() vs. close() |
Date: |
Thu, 20 Oct 2005 12:22:29 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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.