In my opinion you have correctly interpreted the standard, and a
conforming implementation must update the last data modification
timestamp (formerly known as st_mtime) during this operation.
In the 2004 standard the term "st_mtime field" was used, and the
standard states numerous places where it must be updated, regardless of
of whether or not any measurable data modification has actually
occurred.
Unfortunately, you may have uncovered a problem with our re-wording for
fine-grain timestamps in the new revision (where we now call this field
the "last data modification timestamp"). But it gets updated even if, as
you point out, the data has not actually been modified (at least in any
measurable way). I wonder if we need some additional words around the
introduction of file timestamps to warn that the last data modification
timestamp shall be updated even of there is no measurable difference to
the data in the file.
What would you expect to happen if you did:
...
int fd;
struct stat st1, st2;
char buf[BUFSIZ];
ssize_t n;
char *filename = "foo";
fd = open(filename, O_RDWR);
fstat(fd, &st1);
n = read(fd, buf, sizeof(buf));
sleep(3);
lseek(fd, 0, 0);
write(fd, buf, (size_t)n);
close(fd);
fstat(fd, &st2);
...
Again, the data hasn't changed, so should the st_mtime field be updated?
Of course it should!
On Tue, 2007-07-10 at 01:07 -0400, Mike Frysinger wrote:
> can i get an aspect of the open() documentation clarified:
> http://www.opengroup.org/onlinepubs/009695399/functions/open.html
>
> specifically, it states:
> <snip>
> O_TRUNC
> If the file exists and is a regular file, and the file is successfully
> opened O_RDWR or O_WRONLY, its length shall be truncated to 0, and the mode
> and owner shall be unchanged. It shall have no effect on FIFO special files
> or terminal device files. Its effect on other file types is
> implementation-defined. The result of using O_TRUNC with O_RDONLY is
> undefined.
> ...
> If O_TRUNC is set and the file did previously exist, upon successful
> completion, open() shall mark for update the st_ctime and st_mtime fields of
> the file.
> </snip>
>
> if you call open() with the O_TRUNC flag on a file that exists and is already
> 0 bytes, shouldnt the mtime and ctime be updated ? in Linux, this is the
> behavior exhibited but in Darwin, only the ctime is updated. the
> interpretation of the spec from the people at apple is:
> - if the file is already 0 bytes in length, then the file is not modified,
> thus the mtime is not updated
> - "success completion" in the context of O_TRUNC means "if the file is
> actually truncated" instead of the common interpretation of "open returned a
> valid file descriptor and not an error"
> - "shall mark for update" means that the fields will be updated at some
>point
> in the future, but no guarantee is made as to when that is, nor whether it
> can be queried deterministically via stat() on the filename or fstat() on the
> fd returned by open()
>
> for example, this C snippet:
> ...
> int fd;
> struct stat st1, st2;
> char *filename = "foo";
> unlink(filename);
> fd = open(filename, O_WRONLY|O_CREAT|O_TRUNC, 0644);
> close(fd);
> stat(filename, &st1);
> sleep(3);
> fd = open(filename, O_WRONLY|O_CREAT|O_TRUNC, 0644);
> close(fd);
> stat(filename, &st2);
> ...
>
> the behavior in Darwin is that only the st_ctime field would change between
> those two stat calls even though POSIX states that both st_ctime and st_mtime
> shall be updated
> -mike
|