Eric Blake <[EMAIL PROTECTED]> 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.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
