[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);
     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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]