> I wasn't deliberately being tongue-in-cheek; I believe this is a bug,
> pure and simple.  Two ways (read/write vs mmap) of accessing a single
> object (the underlying file) are defined, but changes made via one
> mechanism are not seen via the other until some ill-defined event not
> under anyone's direct control occurs.

Actually, that mechanism is msync.  It's been around for a long time
(in a couple of slightly differing forms, but the basic operations
have stayed pretty much the same).

The problem is that many 'groups' of programs (software systems) want to do:

> two
> programs try to operate on the same file at once, one using read/write
> and the other using mmap.

_without_ bothering to use msync().


Anyway, this is off the topic of the original question.  As far as I
know, some pains were gone to to make sure that (though the VM system
and buffer cache are not merged) changes were propagated automatically
(i.e. not reqiring msync()).  I'm not 100% it does that, because I
don't care about that functionality.  But there were people who I
_thought_ made it do so.

Note that I don't describe "that" as "the right thing."  I think it's
wrong for applications to assume consistency unless they use msync().
Why should the whole system have to pay for consistency, when most
uses/programs don't care?



cgd
(not speaking for Digital, etc.)