Keith Owens wrote:
>
> On Mon, 10 Jun 2002 23:17:27 -0700,
> Andrew Morton <akpm@zip.com.au> wrote:
> >Keith Owens wrote:
> >>
> >> fd = open("foo", O_RDWR);
> >> map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> >> ... modify the mapped pages ...
> >> munmap(map, size);
> >> close(fd);
> >>
> >> The timestamp on foo is not updated, even though the contents have
> >> changed. Adding msync(map, size, MS_[A]SYNC) before munmap makes no
> >> difference. 2.4.19-pre10 has no obvious fixes for this problem.
>
> >What do the standards say?
> >
> >http://www.opengroup.org/onlinepubs/007904975/functions/mmap.html
> >
> > The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED
> > and PROT_WRITE shall be marked for update at some point in the interval
> > between a write reference to the mapped region and the next call to msync() with
> > MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is
> > no such call and if the underlying file is modified as a result of a write reference,
> > then these fields shall be marked for update at some time after the write reference.
>
> That says nothing about a file where the only updates are via mmap. My
> file had grown to its final size so there were no more writes, only
> pages being dirtied via mmap.
It is specifically referring to updates via mmap! "a write reference
to the mapped region". This is the mmap documentation.
What you want is what the standard says we should do. And we aren't
doing it. Your application should perform msync(MS_ASYNC) and the
mtime should be updated.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:21 EST